* [PATCH 2/2] arm64: alternatives: Work around NOP generation with broken assembler
From: Marc Zyngier @ 2016-12-05 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c7de1968-7d50-a435-56ea-a7f3e9cb52da@arm.com>
On 05/12/16 10:58, Marc Zyngier wrote:
> On 05/12/16 10:05, Will Deacon wrote:
>> On Sat, Dec 03, 2016 at 02:05:38PM +0000, Marc Zyngier wrote:
>>> When compiling a .inst directive in an alternative clause with
>>> a rather old version of gas (circa 2.24), and when used with
>>> the alternative_else_nop_endif feature, the compilation fails
>>> with a rather cryptic message such as:
>>>
>>> arch/arm64/lib/clear_user.S:33: Error: bad or irreducible absolute expression
>>>
>>> which is caused by the bug described in eb7c11ee3c5c ("arm64:
>>> alternative: Work around .inst assembler bugs").
>>>
>>> This effectively prevents the use of the "nops" macro, which
>>> requires the number of instruction as a parameter (the assembler
>>> is confused and unable to compute the difference between two labels).
>>>
>>> As an alternative(!), use the .fill directive to output the number
>>> of required NOPs (.fill has the good idea to output the fill pattern
>>> in the endianness of the instruction stream).
>>
>> Are you sure about that? The gas docs say:
>>
>> `The contents of each repeat bytes is taken from an 8-byte number. The
>> highest order 4 bytes are zero. The lowest order 4 bytes are value rendered
>> in the byte-order of an integer on the computer as is assembling for.'
>>
>> and I'd expect "integer" to refer to data values, rather than instructions.
>
> My tests on 2.24 and 2.25 seem to show that the output is always LE,
> which could be another GAS issue. I've asked the binutils people for
> information.
Well, my testing was wrong, as objdump -d was lying to me by displaying
something in little-endian form. Time for some more head scratching.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 1/5] spi: Add basic support for Armada 3700 SPI Controller
From: Mark Brown @ 2016-12-05 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201102719.4291-2-romain.perier@free-electrons.com>
On Thu, Dec 01, 2016 at 11:27:15AM +0100, Romain Perier wrote:
> +config SPI_ARMADA_3700
> + tristate "Marvell Armada 3700 SPI Controller"
> + depends on ARCH_MVEBU && OF
Why does this not have a COMPILE_TEST dependency?
> + /* Reset SPI unit */
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val |= A3700_SPI_SRST;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> +
> + for (i = 0; i < A3700_SPI_TIMEOUT; i++)
> + udelay(1);
Why not just do a single udelay()?
> +static irqreturn_t a3700_spi_interrupt(int irq, void *dev_id)
> +{
> + struct spi_master *master = dev_id;
> + struct a3700_spi *a3700_spi;
> + u32 cause;
> +
> + a3700_spi = spi_master_get_devdata(master);
> +
> + /* Get interrupt causes */
> + cause = spireg_read(a3700_spi, A3700_SPI_INT_STAT_REG);
> +
> + /* mask and acknowledge the SPI interrupts */
> + spireg_write(a3700_spi, A3700_SPI_INT_MASK_REG, 0);
> + spireg_write(a3700_spi, A3700_SPI_INT_STAT_REG, cause);
> +
> + /* Wake up the transfer */
> + if (a3700_spi->wait_mask & cause)
> + complete(&a3700_spi->done);
> +
> + return IRQ_HANDLED;
> +}
This reports that we handled an interrupt even if we did not in fact
handle an interrupt. It's also a bit dodgy that it doesn't check what
the interrupt was but that's less serious.
> + master->bus_num = (pdev->id != -1) ? pdev->id : 0;
At most this should be just setting the bus number to pdev->id like
other drivers do.
> + ret = clk_prepare_enable(spi->clk);
> + if (ret) {
> + dev_err(dev, "could not prepare clk: %d\n", ret);
> + goto error;
> + }
I'd expect the hardware prepare/unprepare to be managing the enable and
disable of the clock in order to save a little power.
> + dev_info(dev, "Marvell Armada 3700 SPI Controller at 0x%08lx, irq %d\n",
> + (unsigned long)res->start, spi->irq);
This is just adding noise to the boot, remove it. It's not telling us
anything we read from the hardware or anything.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161205/bce7957d/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: Add CMDLINE_EXTEND
From: Catalin Marinas @ 2016-12-05 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61060b44-64a9-d628-4faf-3a7ae06048aa@infradead.org>
Hi Geoff,
On Fri, Dec 02, 2016 at 02:17:02PM -0800, Geoff Levand wrote:
> The device tree code already supports CMDLINE_EXTEND,
> so add the config option to make it available on arm64.
What's your use-case for this patch? Note that both CMDLINE_FORCE and
CMDLINE_EXTEND (if we introduce it) are ignored by the EFI stub.
However, we don't seem to have stated this anywhere.
--
Catalin
^ permalink raw reply
* [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2016-12-05 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205112347.GF19891@ulmo.ba.sec>
2016-12-05 12:23 GMT+01:00 Thierry Reding <thierry.reding@gmail.com>:
> On Mon, Dec 05, 2016 at 12:08:32PM +0100, Benjamin Gaignard wrote:
>> 2016-12-05 7:53 GMT+01:00 Thierry Reding <thierry.reding@gmail.com>:
>> > On Fri, Dec 02, 2016 at 11:17:18AM +0100, Benjamin Gaignard wrote:
>> >> Define bindings for pwm-stm32
>> >>
>> >> version 2:
>> >> - use parameters instead of compatible of handle the hardware configuration
>> >>
>> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> >> ---
>> >> .../devicetree/bindings/pwm/pwm-stm32.txt | 38 ++++++++++++++++++++++
>> >> 1 file changed, 38 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> >> new file mode 100644
>> >> index 0000000..575b9fb
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> >> @@ -0,0 +1,38 @@
>> >> +STMicroelectronics PWM driver bindings for STM32
>> >
>> > Technically this bindings describe devices, so "driver binding" is a
>> > somewhat odd wording. Perhaps:
>> >
>> > STMicroelectronics STM32 General Purpose Timer PWM bindings
>> >
>> > ?
>> done
>>
>> >
>> >> +
>> >> +Must be a sub-node of STM32 general purpose timer driver
>> >> +Parent node properties are describe in ../mfd/stm32-general-purpose-timer.txt
>> >
>> > Again, "driver parent node" is odd. Perhaps:
>> >
>> > Must be a sub-node of an STM32 General Purpose Timer device tree
>> > node. See ../mfd/stm32-general-purpose-timer.txt for details about
>> > the parent node.
>> >
>> > ?
>>
>> done
>>
>> >
>> >> +Required parameters:
>> >> +- compatible: Must be "st,stm32-pwm"
>> >> +- pinctrl-names: Set to "default".
>> >> +- pinctrl-0: List of phandles pointing to pin configuration nodes
>> >> + for PWM module.
>> >> + For Pinctrl properties, please refer to [1].
>> >
>> > Your indentation and capitalization are inconsistent. Also, please refer
>> > to the pinctrl bindings by relative path and inline, rather than as a
>> > footnote reference.
>>
>> OK
>>
>> >
>> >> +
>> >> +Optional parameters:
>> >> +- st,breakinput: Set if the hardware have break input capabilities
>> >> +- st,breakinput-polarity: Set break input polarity. Default is 0
>> >> + The value define the active polarity:
>> >> + - 0 (active LOW)
>> >> + - 1 (active HIGH)
>> >
>> > Could we fold these into a single property? If st,breakinput-polarity is
>> > not present it could simply mean that there is no break input, and if it
>> > is present you don't have to rely on a default.
>>
>> I need to know if I have to activate breakinput feature and on which level
>> I will rewrite it like that:
>> Optional parameters:
>> - st,breakinput-polarity-high: Set if break input polarity is active
>> on high level.
>> - st,breakinput-polarity-high: Set if break input polarity is active
>> on low level.
>
> How is that different from a single property:
>
> Optional properties:
> - st,breakinput-polarity: If present, a break input is available
> for the channel. In that case the property value denotes the
> polarity of the break input:
> - 0: active low
> - 1: active high
>
> ?
For break input feature I need two information: do I have to active it
and if activated
on which level.
I have two solutions:
- one parameter with a value (0 or 1) -> st,breakinput-polarity
- two parameters without value -> st,breakinput-active-high and
st,breakinput-active-low
By default break input feature is disabled
>
>> > The pwm- prefix is rather redundant since the node is already named pwm.
>> > Why not simply st,channels? Or simply channels, since it's not really
>> > anything specific to this hardware.
>> >
>> > Come to think of it, might be worth having a discussion with our DT
>> > gurus about what their stance is on using the # as prefix for numbers
>> > (such as in #address-cells or #size-cells). This could be #channels to
>> > mark it more explicitly as representing a count.
>> >
>> >> +- st,32bits-counter: Set if the hardware have a 32 bits counter
>> >> +- st,complementary: Set if the hardware have complementary output channels
>> >
>> > "hardware has" and also maybe mention explicitly that this is a boolean
>> > property. Otherwise people might be left wondering what it should be set
>> > to. Or maybe word this differently to imply that it's boolean:
>> >
>> > - st,32bits-counter: if present, the hardware has a 32 bit counter
>> > - st,complementary: if present, the hardware has a complementary
>> > output channel
>>
>> I found a way to detect, at probe time, the number of channels, counter size,
>> break input capability and complementary channels so I will remove
>> "st,breakinput", "st,32bits-counter", "st,complementary" and "st,pwm-num-chan"
>> parameters
>
> Oh hey, that's very neat. I suppose in that case my comment above about
> the break input polarity is somewhat obsoleted. Still I think you won't
> need two properties. Instead you can follow what other similar
> properties have done: choose a default (often low-active) and have a
> single optional property to override the default (often high-active).
>
> In your case:
>
> - st,breakinput-active-high: Some channels have a break input,
> whose polarity will be active low by default. If this
> property is present, the channel will be configured with an
> active high polarity for the break input.
>
> Thierry
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
From: Thierry Reding @ 2016-12-05 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks5j2e-EQEf74YSduboNnCiWC7+e_PD5aAz5XdFA1tGztQ@mail.gmail.com>
On Mon, Dec 05, 2016 at 01:12:25PM +0100, Benjamin Gaignard wrote:
> 2016-12-05 12:23 GMT+01:00 Thierry Reding <thierry.reding@gmail.com>:
> > On Mon, Dec 05, 2016 at 12:08:32PM +0100, Benjamin Gaignard wrote:
> >> 2016-12-05 7:53 GMT+01:00 Thierry Reding <thierry.reding@gmail.com>:
> >> > On Fri, Dec 02, 2016 at 11:17:18AM +0100, Benjamin Gaignard wrote:
> >> >> Define bindings for pwm-stm32
> >> >>
> >> >> version 2:
> >> >> - use parameters instead of compatible of handle the hardware configuration
> >> >>
> >> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> >> >> ---
> >> >> .../devicetree/bindings/pwm/pwm-stm32.txt | 38 ++++++++++++++++++++++
> >> >> 1 file changed, 38 insertions(+)
> >> >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> >> new file mode 100644
> >> >> index 0000000..575b9fb
> >> >> --- /dev/null
> >> >> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> >> @@ -0,0 +1,38 @@
> >> >> +STMicroelectronics PWM driver bindings for STM32
> >> >
> >> > Technically this bindings describe devices, so "driver binding" is a
> >> > somewhat odd wording. Perhaps:
> >> >
> >> > STMicroelectronics STM32 General Purpose Timer PWM bindings
> >> >
> >> > ?
> >> done
> >>
> >> >
> >> >> +
> >> >> +Must be a sub-node of STM32 general purpose timer driver
> >> >> +Parent node properties are describe in ../mfd/stm32-general-purpose-timer.txt
> >> >
> >> > Again, "driver parent node" is odd. Perhaps:
> >> >
> >> > Must be a sub-node of an STM32 General Purpose Timer device tree
> >> > node. See ../mfd/stm32-general-purpose-timer.txt for details about
> >> > the parent node.
> >> >
> >> > ?
> >>
> >> done
> >>
> >> >
> >> >> +Required parameters:
> >> >> +- compatible: Must be "st,stm32-pwm"
> >> >> +- pinctrl-names: Set to "default".
> >> >> +- pinctrl-0: List of phandles pointing to pin configuration nodes
> >> >> + for PWM module.
> >> >> + For Pinctrl properties, please refer to [1].
> >> >
> >> > Your indentation and capitalization are inconsistent. Also, please refer
> >> > to the pinctrl bindings by relative path and inline, rather than as a
> >> > footnote reference.
> >>
> >> OK
> >>
> >> >
> >> >> +
> >> >> +Optional parameters:
> >> >> +- st,breakinput: Set if the hardware have break input capabilities
> >> >> +- st,breakinput-polarity: Set break input polarity. Default is 0
> >> >> + The value define the active polarity:
> >> >> + - 0 (active LOW)
> >> >> + - 1 (active HIGH)
> >> >
> >> > Could we fold these into a single property? If st,breakinput-polarity is
> >> > not present it could simply mean that there is no break input, and if it
> >> > is present you don't have to rely on a default.
> >>
> >> I need to know if I have to activate breakinput feature and on which level
> >> I will rewrite it like that:
> >> Optional parameters:
> >> - st,breakinput-polarity-high: Set if break input polarity is active
> >> on high level.
> >> - st,breakinput-polarity-high: Set if break input polarity is active
> >> on low level.
> >
> > How is that different from a single property:
> >
> > Optional properties:
> > - st,breakinput-polarity: If present, a break input is available
> > for the channel. In that case the property value denotes the
> > polarity of the break input:
> > - 0: active low
> > - 1: active high
> >
> > ?
>
> For break input feature I need two information: do I have to active it
> and if activated
> on which level.
> I have two solutions:
> - one parameter with a value (0 or 1) -> st,breakinput-polarity
> - two parameters without value -> st,breakinput-active-high and
> st,breakinput-active-low
>
> By default break input feature is disabled
Right, what I was suggesting is that you use the first solution because
it's the typical way to use for tristate options. It's also much easier
to test for in practice because for the second solution you have to
parse two properties before you know whether it is active or not.
The second is typically the solution for required properties where only
one of the properties is used to override the default.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161205/e3aed0cd/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Lorenzo Pieralisi @ 2016-12-05 12:26 UTC (permalink / raw)
To: linux-arm-kernel
The introduction of acpi_dma_configure() allows to configure DMA
and related IOMMU for any device that is DMA capable. To achieve
that goal it ensures DMA masks are set-up to sane default values
before proceeding with IOMMU and DMA ops configuration.
On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
called for every device that has an ACPI companion, in that every device
is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
which has the side effect of initializing dma masks also for
pseudo-devices (eg CPUs and memory nodes) and potentially for devices
whose dma masks were not set-up before the acpi_dma_configure() API was
introduced, which may have noxious side effects.
Therefore, in preparation for IORT firmware specific DMA masks set-up,
wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
default expected behaviour on x86/ia64 systems and keeping DMA default
masks set-up on IORT based (ie ARM) arch configurations.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Sricharan R <sricharan@codeaurora.org>
---
Joerg,
pending Rafael's ACK on it, given the 4.10 release timing and that the
series is queued via the IOMMU tree please consider applying this patch to
your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
the x86/ia64 code path; I prefer preventing any issue related to default
dma masks on x86/ia64 so I hope it can get merged along with the rest of
the ACPI IORT SMMU series.
Thanks a lot and apologies,
Lorenzo
drivers/acpi/arm64/iort.c | 22 ++++++++++++++++++++++
drivers/acpi/scan.c | 14 +-------------
include/linux/acpi_iort.h | 2 ++
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 47bace8..e0d2e6e 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
}
/**
+ * iort_set_dma_mask - Set-up dma mask for a device.
+ *
+ * @dev: device to configure
+ */
+void iort_set_dma_mask(struct device *dev)
+{
+ /*
+ * Set default coherent_dma_mask to 32 bit. Drivers are expected to
+ * setup the correct supported mask.
+ */
+ if (!dev->coherent_dma_mask)
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+ /*
+ * Set it to coherent_dma_mask by default if the architecture
+ * code has not set it.
+ */
+ if (!dev->dma_mask)
+ dev->dma_mask = &dev->coherent_dma_mask;
+}
+
+/**
* iort_iommu_configure - Set-up IOMMU configuration for a device.
*
* @dev: device to configure
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 80698d3..93b00cf 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
{
const struct iommu_ops *iommu;
- /*
- * Set default coherent_dma_mask to 32 bit. Drivers are expected to
- * setup the correct supported mask.
- */
- if (!dev->coherent_dma_mask)
- dev->coherent_dma_mask = DMA_BIT_MASK(32);
-
- /*
- * Set it to coherent_dma_mask by default if the architecture
- * code has not set it.
- */
- if (!dev->dma_mask)
- dev->dma_mask = &dev->coherent_dma_mask;
+ iort_set_dma_mask(dev);
iommu = iort_iommu_configure(dev);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index dcb2b60..77e0809 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
u32 iort_msi_map_rid(struct device *dev, u32 req_id);
struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
/* IOMMU interface */
+void iort_set_dma_mask(struct device *dev);
const struct iommu_ops *iort_iommu_configure(struct device *dev);
#else
static inline void acpi_iort_init(void) { }
@@ -45,6 +46,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
u32 req_id)
{ return NULL; }
/* IOMMU interface */
+static inline void iort_set_dma_mask(struct device *dev) { }
static inline
const struct iommu_ops *iort_iommu_configure(struct device *dev)
{ return NULL; }
--
2.10.0
^ permalink raw reply related
* Adding a .platform_init callback to sdhci_arasan_ops
From: Sebastian Frias @ 2016-12-05 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=XrJHFbpbhsJZAEE-HLMe47Ov=BgvHw8ZtfCazzT75pKQ@mail.gmail.com>
Hi Doug,
On 28/11/16 18:46, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 28, 2016 at 6:39 AM, Sebastian Frias <sf84@laposte.net> wrote:
>>> I will try to send another patch with what a different approach
>>>
>>
>> Here's a different approach (I just tested that it built, because I don't have the
>> rk3399 platform):
>>
>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
>> index 410a55b..5be6e67 100644
>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>> @@ -382,22 +382,6 @@ static int sdhci_arasan_resume(struct device *dev)
>> static SIMPLE_DEV_PM_OPS(sdhci_arasan_dev_pm_ops, sdhci_arasan_suspend,
>> sdhci_arasan_resume);
>>
>> -static const struct of_device_id sdhci_arasan_of_match[] = {
>> - /* SoC-specific compatible strings w/ soc_ctl_map */
>> - {
>> - .compatible = "rockchip,rk3399-sdhci-5.1",
>> - .data = &rk3399_soc_ctl_map,
>> - },
>> -
>> - /* Generic compatible below here */
>> - { .compatible = "arasan,sdhci-8.9a" },
>> - { .compatible = "arasan,sdhci-5.1" },
>> - { .compatible = "arasan,sdhci-4.9a" },
>> -
>> - { /* sentinel */ }
>> -};
>> -MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
>> -
>> /**
>> * sdhci_arasan_sdcardclk_recalc_rate - Return the card clock rate
>> *
>> @@ -578,28 +562,18 @@ static void sdhci_arasan_unregister_sdclk(struct device *dev)
>> of_clk_del_provider(dev->of_node);
>> }
>>
>> -static int sdhci_arasan_probe(struct platform_device *pdev)
>> +static int sdhci_rockchip_platform_init(struct sdhci_host *host,
>> + struct platform_device *pdev)
>> {
>> int ret;
>> - const struct of_device_id *match;
>> struct device_node *node;
>> - struct clk *clk_xin;
>> - struct sdhci_host *host;
>> struct sdhci_pltfm_host *pltfm_host;
>> struct sdhci_arasan_data *sdhci_arasan;
>> - struct device_node *np = pdev->dev.of_node;
>> -
>> - host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
>> - sizeof(*sdhci_arasan));
>> - if (IS_ERR(host))
>> - return PTR_ERR(host);
>>
>> pltfm_host = sdhci_priv(host);
>> sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
>> - sdhci_arasan->host = host;
>>
>> - match = of_match_node(sdhci_arasan_of_match, pdev->dev.of_node);
>> - sdhci_arasan->soc_ctl_map = match->data;
>> + sdhci_arasan->soc_ctl_map = &rk3399_soc_ctl_map;
>>
>> node = of_parse_phandle(pdev->dev.of_node, "arasan,soc-ctl-syscon", 0);
>> if (node) {
>> @@ -611,10 +585,107 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>> if (ret != -EPROBE_DEFER)
>> dev_err(&pdev->dev, "Can't get syscon: %d\n",
>> ret);
>> - goto err_pltfm_free;
>> + return -1;
>> }
>> }
>>
>> + if (of_property_read_bool(pdev->dev.of_node, "xlnx,fails-without-test-cd"))
>> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
>> +
>> + return 0;
>> +}
>> +
>> +static int sdhci_rockchip_clock_init(struct sdhci_host *host,
>> + struct platform_device *pdev)
>> +{
>> + struct sdhci_pltfm_host *pltfm_host;
>> + struct sdhci_arasan_data *sdhci_arasan;
>> +
>> + pltfm_host = sdhci_priv(host);
>> + sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
>> +
>> + if (of_device_is_compatible(pdev->dev.of_node,
>> + "rockchip,rk3399-sdhci-5.1"))
>> + sdhci_arasan_update_clockmultiplier(host, 0x0);
>
> This _does_ belong in a Rockchip-specific init function, for now.
I'm not sure I understood. Are you saying that you agree to put this
into a specific function? Essentially agreeing with the concept the
patch is putting forward?
Note, I'm more interested in the concept (i.e.: init functions) and less
in knowing if my patch (which was a quick and dirty thing) properly moved
the functions into the said init functions. For example, I did not move
the code dealing with "arasan,sdhci-5.1", but it could go into another
callback.
Right now there are no "chip-specific" functions.
Just a code in sdhci_arasan_probe() that by checking various compatible
strings and the presence of other specific properties, acts as a way of
"chip-specific" initialisation, because it calls or not some functions.
(or the functions do nothing if some DT properties are not there).
The proposed patch is an attempt to clean up sdhci_arasan_probe() from
all those checks and move them into separate functions, for clarity and
maintainability reasons.
What are your thoughts in that regard?
>From what I've seen in other drivers, for example drivers/net/ethernet/aurora/nb8800.c
One matches the compatible string to get a (likely) chip-specific set of
callbacks to use in the 'probe' function.
Then, adding support for other chips is just a matter of replacing some
of those callbacks with others adapted to a given platform.
> Other platforms might want different values for
> corecfg_clockmultiplier, I think.
>
> If it becomes common to need to set this, it wouldn't be hard to make
> it generic by putting it in the data matched by the device tree, then
> generically call sdhci_arasan_update_clockmultiplier() in cases where
> it is needed. sdhci_arasan_update_clockmultiplier() itself should be
> generic enough to handle it.
>
>
>> +
>> + sdhci_arasan_update_baseclkfreq(host);
>
> If you make soc_ctl_map always part of "struct sdhci_arasan_cs_ops"
> then other platforms will be able to use it.
I thought that soc_ctl_map was specific and for a given platform.
For what is worth, I don't know which of these calls are or can be made
generic or not.
Indeed, I'm not an expert in this code; However, I think that given the
amount of checks for specific properties, probably part of this is chip-
specific, and as such, it would benefit from some re-factoring so that
the chip-specific parts are clearly separated from the rest, instead of
being mixed together inside the probe function.
>
> As argued in my original patch the field "corecfg_baseclkfreq" is
> documented in the generic Arasan document
> <https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdf>
> and thus is unlikely to be Rockchip specific. It is entirely possible
> that not everyone who integrates this IP block will need this register
> set, but in that case they can set an offset as "-1" and they'll be
> fine.
>
> Said another way: the concept of whether or not to set "baseclkfreq"
> doesn't need to be tired to whether or not we're on Rockchip.
>
I see.
For what is worth, the documentation for 'sdhci_arasan_update_baseclkfreq()'
says something like:
* Many existing devices don't seem to do this and work fine. To keep
* compatibility for old hardware where the device tree doesn't provide a
* register map, this function is a noop if a soc_ctl_map hasn't been provided
* for this platform.
>
>> +
>> + return sdhci_arasan_register_sdclk(sdhci_arasan, pltfm_host->clk, &pdev->dev);
>
> This is documented in "bindings/mmc/arasan,sdhci.txt" to be available
> to all people using this driver, not just Rockchip. You should do it
> always. If you don't specify "#clock-cells" in the device tree it
> will be a no-op anyway.
I see, thanks for the explanation.
>
>
>> +}
>> +
>> +static int sdhci_tango_platform_init(struct sdhci_host *host,
>> + struct platform_device *pdev)
>> +{
>> + return 0;
>
> I'll comment in your other patch where you actually had an
> implementation for this.
>
Sounds good. I will reply to you there because now I have a more
complete set of register writes.
Best regards,
Sebastian
>
>> +}
>> +
>> +/* Chip-specific ops */
>> +struct sdhci_arasan_cs_ops {
>> + int (*platform_init)(struct sdhci_host *host,
>> + struct platform_device *pdev);
>> + int (*clock_init)(struct sdhci_host *host,
>> + struct platform_device *pdev);
>> +};
>
> I really think it's a good idea to add the "soc_ctl_map" into this structure.
>
> If nothing else when the next Rockchip SoC comes out that uses this
> then we won't have to do a second level of matching for Rockchip SoCs.
> I'm also a firm believer that others will need "soc_ctl_map" at some
> point in time, but obviously I can't predict the future.
>
>
>> +
>> +static const struct sdhci_arasan_cs_ops sdhci_rockchip_cs_ops = {
>> + .platform_init = sdhci_rockchip_platform_init,
>> + .clock_init = sdhci_rockchip_clock_init,
>> +};
>> +
>> +static const struct sdhci_arasan_cs_ops sdhci_tango_cs_ops = {
>> + .platform_init = sdhci_tango_platform_init,
>> +};
>> +
>> +static const struct of_device_id sdhci_arasan_of_match[] = {
>> + /* SoC-specific compatible strings */
>> + {
>> + .compatible = "rockchip,rk3399-sdhci-5.1",
>> + .data = &sdhci_rockchip_cs_ops,
>> + },
>> + {
>> + .compatible = "sigma,sdio-v1",
>> + .data = &sdhci_tango_cs_ops,
>> + },
>> +
>> + /* Generic compatible below here */
>> + { .compatible = "arasan,sdhci-8.9a" },
>> + { .compatible = "arasan,sdhci-5.1" },
>> + { .compatible = "arasan,sdhci-4.9a" },
>> +
>> + { /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
>> +
>> +static int sdhci_arasan_probe(struct platform_device *pdev)
>> +{
>> + int ret;
>> + const struct of_device_id *match;
>> + struct clk *clk_xin;
>> + struct sdhci_host *host;
>> + struct sdhci_pltfm_host *pltfm_host;
>> + struct sdhci_arasan_data *sdhci_arasan;
>> + const struct sdhci_arasan_cs_ops *cs_ops;
>> +
>> + host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
>> + sizeof(*sdhci_arasan));
>> + if (IS_ERR(host))
>> + return PTR_ERR(host);
>> +
>> + pltfm_host = sdhci_priv(host);
>> + sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
>> + sdhci_arasan->host = host;
>> +
>> + match = of_match_device(sdhci_arasan_of_match, &pdev->dev);
>> + if (match)
>> + cs_ops = match->data;
>> +
>> + /* SoC-specific platform init */
>> + if (cs_ops && cs_ops->platform_init) {
>> + ret = cs_ops->platform_init(host, pdev);
>> + if (ret)
>> + goto err_pltfm_free;
>> + }
>> +
>> sdhci_arasan->clk_ahb = devm_clk_get(&pdev->dev, "clk_ahb");
>> if (IS_ERR(sdhci_arasan->clk_ahb)) {
>> dev_err(&pdev->dev, "clk_ahb clock not found.\n");
>> @@ -642,21 +713,14 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>> }
>>
>> sdhci_get_of_property(pdev);
>> -
>> - if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
>> - sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
>> -
>> pltfm_host->clk = clk_xin;
>>
>> - if (of_device_is_compatible(pdev->dev.of_node,
>> - "rockchip,rk3399-sdhci-5.1"))
>> - sdhci_arasan_update_clockmultiplier(host, 0x0);
>> -
>> - sdhci_arasan_update_baseclkfreq(host);
>> -
>> - ret = sdhci_arasan_register_sdclk(sdhci_arasan, clk_xin, &pdev->dev);
>> - if (ret)
>> - goto clk_disable_all;
>> + /* SoC-specific clock init */
>> + if (cs_ops && cs_ops->clock_init) {
>> + ret = cs_ops->clock_init(host, pdev);
>> + if (ret)
>> + goto clk_disable_all;
>> + }
>>
>> ret = mmc_of_parse(host->mmc);
>> if (ret) {
>>
>>
>> If you are ok with it I can clean it up to submit it properly.
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Sebastian Frias @ 2016-12-05 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=UhVtQQ1PPtLrvra20ja1k9GKs9hyFcrjBUYmyUmQK45Q@mail.gmail.com>
Hi Doug,
On 28/11/16 19:02, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 28, 2016 at 5:28 AM, Sebastian Frias <sf84@laposte.net> wrote:
>> +static void sdhci_tango4_platform_init(struct sdhci_host *host)
>> +{
>> + printk("%s\n", __func__);
>> +
>> + /*
>> + pad_mode[2:0]=0 must be 0
>> + sel_sdio[3]=1 must be 1 for SDIO
>> + inv_sdwp_pol[4]=0 if set inverts the SD write protect polarity
>> + inv_sdcd_pol[5]=0 if set inverts the SD card present polarity
>> + */
>> + sdhci_writel(host, 0x00000008, 0x100 + 0x0);
>
> If I were doing this, I'd probably actually add these fields to the
> "sdhci_arasan_soc_ctl_map", then add a 3rd option to
> sdhci_arasan_syscon_write(). Right now it has 2 modes: "hiword
> update" and "non-hiword update". You could add a 3rd indicating that
> you set config registers by just writing at some offset of the main
> SDHCI registers space.
>
> So you'd add 4 fields:
>
> .tango_pad_mode = { .reg = 0x0000, .width = 3, .shift = 0 },
> .sel_sdio = { .reg = 0x0000, .width = 1, .shift = 3},
> .inv_sdwp_pol = { .reg = 0x0000, .width = 1, .shift = 4},
> .inv_sdcd_pol = { .reg = 0x0000, .width = 1, .shift = 5},
Right now I'm using something like:
+ val = 0;
+ val |= PAD_MODE(0); /* must be 0 */
+ val |= SEL_SDIO; /* enable SDIO */
+ sdhci_writel(host, val, 0x100 + 0x0);
+
+ val = 0;
+ val |= TIMEOUT_CLK_UNIT_MHZ; /* unit: MHz */
+ val |= TIMEOUT_CLK_FREQ(52); /* timeout clock: 52MHz */
+ val |= BUS_CLK_FREQ_FOR_SD_CLK(200); /* SDIO clock: 200MHz (TODO: get from DT) */
+ val |= MAX_BLOCK_LENGTH(3); /* max block size: 4096 bytes */
+ val |= EXTENDED_MEDIA_BUS_SUPPORTED; /* DT? */
+ val |= ADMA2_SUPPORTED; /* DT? */
+ val |= HIGH_SPEED_SUPPORTED; /* DT? */
+ val |= SDMA_SUPPORTED; /* DT? */
+ val |= SUSPEND_RESUME_SUPPORTED; /* DT? */
+ val |= VOLTAGE_3_3_V_SUPPORTED; /* DT? */
+#if 0
+ val |= VOLTAGE_1_8_V_SUPPORTED; /* DT? */
+#endif
+ val |= ASYNCHRONOUS_IRQ_SUPPORTED; /* DT? */
+ val |= SLOT_TYPE_REMOVABLE; /* DT? */
+ val |= SDR50_SUPPORTED; /* DT? */
+ sdhci_writel(host, val, 0x100 + 0x40);
+
+ val = 0;
+ val |= TIMER_COUNT_FOR_RETUNING(1); /* DT? */
+ val |= CLOCK_MULTIPLIER(0); /* DT? */
+ val |= SPI_MODE_SUPPORTED; /* DT? */
+ val |= SPI_BLOCK_MODE_SUPPORTED; /* DT? */
+ sdhci_writel(host, val, 0x100 + 0x44);
+
+ sdhci_writel(host, 0x0004022c, 0x100 + 0x28);
+ sdhci_writel(host, 0x00000002, 0x100 + 0x2c);
+
+ sdhci_writel(host, 0x00600000, 0x100 + 0x50);
which seems much easier to handle (and portable).
At any rate, one thing to note from this is that many of these
bits should probably be initialised based on DT, right?
For example, the DT has a "non-removable" property, which I think
should be used to setup SLOT_TYPE_EMBEDDED (if the property is
present) or SLOT_TYPE_REMOVABLE (if the property is not present)
Looking at Documentation/devicetree/bindings/mmc/mmc.txt we can see
more related properties:
Optional properties:
- bus-width: Number of data lines, can be <1>, <4>, or <8>. The default
will be <1> if the property is absent.
- wp-gpios: Specify GPIOs for write protection, see gpio binding
- cd-inverted: when present, polarity on the CD line is inverted. See the note
below for the case, when a GPIO is used for the CD line
- wp-inverted: when present, polarity on the WP line is inverted. See the note
below for the case, when a GPIO is used for the WP line
- disable-wp: When set no physical WP line is present. This property should
only be specified when the controller has a dedicated write-protect
detection logic. If a GPIO is always used for the write-protect detection
logic it is sufficient to not specify wp-gpios property in the absence of a WP
line.
- max-frequency: maximum operating clock frequency
- no-1-8-v: when present, denotes that 1.8v card voltage is not supported on
this system, even if the controller claims it is.
- cap-sd-highspeed: SD high-speed timing is supported
- cap-mmc-highspeed: MMC high-speed timing is supported
- sd-uhs-sdr12: SD UHS SDR12 speed is supported
- sd-uhs-sdr25: SD UHS SDR25 speed is supported
- sd-uhs-sdr50: SD UHS SDR50 speed is supported
- sd-uhs-sdr104: SD UHS SDR104 speed is supported
- sd-uhs-ddr50: SD UHS DDR50 speed is supported
...
which makes me wonder, what is the recommended way of dealing with this?
- Should I use properties on the DT? If so, then I need to add code to set
up the register properly.
- Should I hardcode these values use a minimal DT? If so, then I need an
init function to put all this.
- Should I hardcode stuff at u-Boot level? If so, nothing is required and
should work without any modifications to the Arasan Linux driver.
It appears that the Linux driver is expecting most of these fields to be
hardcoded and "pre-set" before (maybe by the bootloader) it starts, hence
the lack of any "init" function so far.
>
> In your platform-specific init you're proposing you could set
> tango_pad_mode to 0. That seems tango-specific.
>
> You'd want to hook into "set_ios" for setting sel_sdio or not. That's
> important if anyone ever wants to plug in an external SDIO card to
> your slot. This one good argument for putting this in
> sdhci_arasan_soc_ctl_map, since you wouldn't want to do a
> compatibility matching every time set_ios is called.
Thanks for the advice, I will look into that.
>
> I'd have to look more into the whole SD/WP polarity issue. There are
> already so many levels of inversion for these signals in Linux that
> it's confusing. It seems like you might just want to hardcode them to
> "0" and let users use all the existing ways to invert things... You
> could either put that hardcoding into your platform init code or (if
> you're using sdhci_arasan_soc_ctl_map) put it in the main init code so
> that if anyone else needs to init similar signals then they can take
> advantage of it.
Yes, I think I will leave them to 0.
>
> --
>
> One random side note is that as currently documented you need to
> specify a "shift" of -1 for any sdhci_arasan_soc_ctl_map fields you
> aren't using. That seems stupid--not sure why I did that. It seems
> better to clue off "width = 0" so that you could just freely not init
> any fields you don't need.
I see.
So far I'm not really convinced about using "soc_ctl_map" because what I
have so far is more portable, and can easily be put as is somewhere else
(i.e.: in different flavors of bootloaders)
Best regards,
Sebastian
^ permalink raw reply
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Herbert Xu @ 2016-12-05 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480934922-20732-1-git-send-email-clabbe.montjoie@gmail.com>
On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> From: LABBE Corentin <clabbe.montjoie@gmail.com>
>
> The Security System have a PRNG.
> This patch add support for it as an hwrng.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Please don't add PRNGs to hwrng. If we have existing PRNGs in
there please let me know so that we can remove them.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: YT Shen @ 2016-12-05 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480492728.32217.20.camel@mtksdaap41>
Hi CK,
On Wed, 2016-11-30 at 15:58 +0800, CK Hu wrote:
> Hi, YT:
>
> some comments inline.
>
> On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> > This patch update enable/disable flow of DSI module.
> > Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> > In this case: DSI -> panel, the DSI sub driver flow should be updated.
> > We need to initialize DSI first so that we can send commands to panel.
> >
> > Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> > Signed-off-by: YT Shen <yt.shen@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 101 +++++++++++++++++++++++++++++--------
> > 1 file changed, 80 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index ded4202..0569f2e 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -126,6 +126,10 @@
> > #define CLK_HS_POST (0xff << 8)
> > #define CLK_HS_EXIT (0xff << 16)
> >
> > +#define DSI_VM_CMD_CON 0x130
> > +#define VM_CMD_EN BIT(0)
> > +#define TS_VFP_EN BIT(5)
> > +
> > #define DSI_CMDQ0 0x180
> > #define CONFIG (0xff << 0)
> > #define SHORT_PACKET 0
> > @@ -249,7 +253,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> > * we set mipi_ratio is 1.05.
> > */
> > - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> > + dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
> > + dsi->data_rate /= (dsi->lanes * 1000 * 10);
>
> This looks like a bug fix that use lanes to calculate data rate.
This part add support when dsi->lanes != 4.
>
> > + DRM_DEBUG_DRIVER("set mipitx's data rate: %dMHz\n", dsi->data_rate);
> >
> > ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> > if (ret < 0) {
> > @@ -333,16 +339,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> > u32 vid_mode = CMD_MODE;
> >
> > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> > - vid_mode = SYNC_PULSE_MODE;
> > -
> > - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> > - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> > + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> > vid_mode = BURST_MODE;
> > + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> > + vid_mode = SYNC_PULSE_MODE;
> > + else
> > + vid_mode = SYNC_EVENT_MODE;
> > }
> >
> > writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> > }
> >
> > +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> > +{
> > + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> > + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> > +}
> > +
> > static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> > {
> > struct videomode *vm = &dsi->vm;
> > @@ -480,6 +493,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> > writel(1, dsi->regs + DSI_START);
> > }
> >
> > +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> > +{
> > + writel(0, dsi->regs + DSI_START);
> > +}
> > +
> > +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> > +{
> > + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> > +}
> > +
> > static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> > {
> > u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> > @@ -538,6 +561,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> > return IRQ_HANDLED;
> > }
> >
> > +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> > +{
> > + mtk_dsi_irq_data_clear(dsi, irq_flag);
> > + mtk_dsi_set_cmd_mode(dsi);
> > +
> > + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> > + DRM_ERROR("failed to switch cmd mode\n");
> > + return -ETIME;
> > + } else {
> > + return 0;
> > + }
> > +}
> > +
> > static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> > {
> > if (WARN_ON(dsi->refcount == 0))
> > @@ -546,11 +582,6 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> > if (--dsi->refcount != 0)
> > return;
> >
> > - mtk_dsi_lane0_ulp_mode_enter(dsi);
> > - mtk_dsi_clk_ulp_mode_enter(dsi);
> > -
> > - mtk_dsi_disable(dsi);
> > -
> > clk_disable_unprepare(dsi->engine_clk);
> > clk_disable_unprepare(dsi->digital_clk);
> >
> > @@ -564,13 +595,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> > if (dsi->enabled)
> > return;
> >
> > - if (dsi->panel) {
> > - if (drm_panel_prepare(dsi->panel)) {
> > - DRM_ERROR("failed to setup the panel\n");
> > - return;
> > - }
> > - }
> > -
> > ret = mtk_dsi_poweron(dsi);
> > if (ret < 0) {
> > DRM_ERROR("failed to power on dsi\n");
> > @@ -578,21 +602,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> > }
> >
> > mtk_dsi_rxtx_control(dsi);
> > + mtk_dsi_ps_control_vact(dsi);
> > + mtk_dsi_set_vm_cmd(dsi);
>
> Even though dsi does not directly connect to panel, you newly set vm cmd
> here. This looks like a bug fix.
We will remove this if it is not necessary.
>
> > + mtk_dsi_config_vdo_timing(dsi);
> > + mtk_dsi_set_interrupt_enable(dsi);
> >
> > mtk_dsi_clk_ulp_mode_leave(dsi);
> > mtk_dsi_lane0_ulp_mode_leave(dsi);
> > mtk_dsi_clk_hs_mode(dsi, 0);
> > - mtk_dsi_set_mode(dsi);
> >
> > - mtk_dsi_ps_control_vact(dsi);
> > - mtk_dsi_config_vdo_timing(dsi);
> > - mtk_dsi_set_interrupt_enable(dsi);
> > + if (dsi->panel) {
> > + if (drm_panel_prepare(dsi->panel)) {
> > + DRM_ERROR("failed to prepare the panel\n");
> > +
> > + mtk_dsi_stop(dsi);
>
> You never start dsi before here, why do you stop dsi here?
>
> > + mtk_dsi_poweroff(dsi);
>
> Refer to next comment, you may goto undo item in bottom of this
> function.
>
> > + return;
> > + }
> > + }
> >
> > mtk_dsi_set_mode(dsi);
> > mtk_dsi_clk_hs_mode(dsi, 1);
> >
> > mtk_dsi_start(dsi);
> >
> > + if (dsi->panel) {
> > + if (drm_panel_enable(dsi->panel)) {
> > + DRM_ERROR("failed to enable the panel\n");
> > +
> > + if (drm_panel_unprepare(dsi->panel))
> > + DRM_ERROR("failed to unprepare the panel\n");
> > +
> > + mtk_dsi_stop(dsi);
>
> I think you should stop dsi before panel unprepare. Otherwise, why not
> move these undo item to the bottom of this function. For example:
>
> if (drm_panel_enable(dsi->panel)) {
> DRM_ERROR("failed to enable the panel\n");
> goto stop_dsi;
>
> ...
>
> dsi->enabled = true;
> return;
>
> stop_dsi:
> mtk_dsi_stop(dsi);
> if (drm_panel_unprepare(dsi->panel))
> DRM_ERROR("failed to unprepare the panel\n");
> poweroff_dsi:
> mtk_dsi_poweroff(dsi);
> return;
>
We will move the error handling to the bottom of this function.
> > + mtk_dsi_poweroff(dsi);
> > + return;
> > + }
> > + }
> > +
> > dsi->enabled = true;
> > }
> >
> > @@ -608,6 +654,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> > }
> > }
> >
> > + mtk_dsi_stop(dsi);
>
> Even though dsi does not directly connect to panel, you newly stop dsi
> here. This looks like a bug fix.
>
> > + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
>
> ditto.
>
> > + if (dsi->panel) {
> > + if (drm_panel_unprepare(dsi->panel))
> > + DRM_ERROR("failed to unprepare the panel\n");
> > + }
> > + }
> > +
> > + mtk_dsi_reset_engine(dsi);
>
> ditto.
>
> > + mtk_dsi_lane0_ulp_mode_enter(dsi);
> > + mtk_dsi_clk_ulp_mode_enter(dsi);
> > + mtk_dsi_disable(dsi);
> > +
> > mtk_dsi_poweroff(dsi);
> >
> > dsi->enabled = false;
>
> Regards,
> CK
>
^ permalink raw reply
* [stable:PATCH 0/3] PAN fixes backport for v4.4.35
From: Greg KH @ 2016-12-05 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584538CC.50807@arm.com>
On Mon, Dec 05, 2016 at 09:52:12AM +0000, James Morse wrote:
> Hi Greg,
>
> On 02/12/16 17:23, Greg KH wrote:
> > On Fri, Dec 02, 2016 at 04:42:44PM +0000, James Morse wrote:
> >> Hi linux-stable,
> >>
> >> This is the backport of the recent PAN fixes series for v4.4.35.
> >> Original series:
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461806.html
> >
> > Why just 4.4-stable? What about 4.8-stable?
>
> Patch 1 doesn't backport easily. I was going to do v4.8 next, but thought one at
> a time would be the least confusing...
>
> (I don't seem to be very good at predicting what is confusing!)
Adding a patch to an "old" stable kernel would be odd if the latest
stable kernel also doesn't have it, right? I need for it to be in 4.8
before I can take it into 4.4, sorry.
So I'll hold off on applying these until that happens.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Tomi Valkeinen @ 2016-12-05 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480420624-23544-2-git-send-email-bgolaszewski@baylibre.com>
On 29/11/16 13:57, Bartosz Golaszewski wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
> 2 files changed, 75 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 711b9ad..d864f11 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -50,6 +50,53 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga_bridge {
> + compatible = "dumb-vga-dac";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + vga_bridge_in: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&display_out_vga>;
> + };
> + };
> +
> + port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + vga_bridge_out: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_con_in>;
> + };
> + };
> + };
> + };
> +
> + vga {
> + compatible = "vga-connector";
> +
> + ddc-i2c-bus = <&i2c0>;
> +
> + port {
> + vga_con_in: endpoint {
> + remote-endpoint = <&vga_bridge_out>;
> + };
> + };
> + };
> };
>
> &pmx_core {
> @@ -235,3 +282,14 @@
> &memctrl {
> status = "okay";
> };
> +
> +&display {
> + status = "okay";
> +};
> +
> +&display_out {
> + display_out_vga: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&vga_bridge_in>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 4070619..5f4ba2e 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -454,6 +454,23 @@
> reg = <0x213000 0x1000>;
> interrupts = <52>;
> status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + display_in: port at 0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + };
> +
> + display_out: port at 1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> + };
> + };
> };
It's a bit difficult to follow this as there's been so many patches
going around. But I take the above is the LCDC node in the base da850
dtsi file? In that case, what is the display_in supposed to present?
It's the first node in the "display chain", so it has no input.
Also, don't touch da850.dtsi here, just add the "ports" node in the
da850-lcdk.dts file.
If the da850.dtsi has not been merged yet, I'd change the name of the
lcdc node to something else than "display". It's rather vague. If it's
named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
refer to "lcdc".
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161205/8a7836a6/attachment.sig>
^ permalink raw reply
* [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings
From: YT Shen @ 2016-12-05 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGS+omDmMq7AEnyDzo4Oih_f+g4DE1Jz6xiV=+_3JGtSAfd+-Q@mail.gmail.com>
Hi Daniel,
On Wed, 2016-11-30 at 14:42 +0800, Daniel Kurtz wrote:
> Hi YT,
>
>
> On Fri, Nov 25, 2016 at 6:34 PM, YT Shen <yt.shen@mediatek.com> wrote:
> >
> > There are some hardware settings changed, between MT8173 & MT2701:
> > DISP_OVL address offset changed, color format definition changed.
> > DISP_RDMA fifo size changed.
> > DISP_COLOR offset changed.
> > MIPI_TX pll setting changed.
> > And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
>
> Sorry, I have not had time to thoroughly review the new patch set, but
> one quick comment:
>
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > index 22a33ee..cfaa760 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
> > struct drm_crtc_state *state);
> > };
> >
> > +struct mtk_ddp_comp_driver_data {
> > + unsigned int color_offset;
> > +};
> > +
> > struct mtk_ddp_comp {
> > struct clk *clk;
> > void __iomem *regs;
> > @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> > struct device *larb_dev;
> > enum mtk_ddp_comp_id id;
> > const struct mtk_ddp_comp_funcs *funcs;
> > + const struct mtk_ddp_comp_driver_data *data;
>
> I want to avoid adding this generic pointer here to all mtk_ddp_comp,
> since this is only used by the color component.
> Instead, define color specific types:
>
> struct mtk_disp_color_data {
> unsigned int offset;
> };
>
> struct mtk_disp_color {
> struct mtk_ddp_comp ddp_comp;
> const struct mtk_disp_color_data *data;
> };
>
> Then, add another comp_type check and fetch the dev data in
> mtk_drm_probe() or maybe mtk_ddp_comp_init().
>
> -Dan
OK, we will remove the color data pointer from generic mtk_ddp_comp.
Thanks.
Regards,
yt.shen
^ permalink raw reply
* [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: Corentin Labbe @ 2016-12-05 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205123705.GA10732@gondor.apana.org.au>
On Mon, Dec 05, 2016 at 08:37:05PM +0800, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 11:48:42AM +0100, Corentin Labbe wrote:
> > From: LABBE Corentin <clabbe.montjoie@gmail.com>
> >
> > The Security System have a PRNG.
> > This patch add support for it as an hwrng.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>
> Please don't add PRNGs to hwrng. If we have existing PRNGs in
> there please let me know so that we can remove them.
>
So how to expose PRNG to user space ? or more generally how to "use" a PRNG ?
I found hisi-rng, crypto4xx_ and exynos-rng which seems to be PRNG used as hwrng.
Regards
^ permalink raw reply
* [PATCH v10 13/13] drm/mediatek: add support for Mediatek SoC MT2701
From: YT Shen @ 2016-12-05 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1be9b66b-eff2-4232-fe17-5d1735999d0b@gmail.com>
On Wed, 2016-11-30 at 15:03 +0100, Matthias Brugger wrote:
>
> On 25/11/16 11:34, YT Shen wrote:
>
> > static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-rdma",
> > + .data = &mt2701_rdma_driver_data},
> > { .compatible = "mediatek,mt8173-disp-rdma",
> > .data = &mt8173_rdma_driver_data},
> > {},
>
> [...]
>
> > static const struct of_device_id ddp_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> > { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> > {},
> > };
>
> [...]
>
> >
> > static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-color",
> > + .data = &mt2701_color_driver_data},
> > { .compatible = "mediatek,mt8173-disp-color",
> > .data = &mt8173_color_driver_data},
> > {},
>
> [...]
>
> > static const struct of_device_id mtk_drm_of_ids[] = {
> > + { .compatible = "mediatek,mt2701-mmsys",
> > + .data = &mt2701_mmsys_driver_data},
> > { .compatible = "mediatek,mt8173-mmsys",
> > .data = &mt8173_mmsys_driver_data},
> > { }
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index 0569f2e..f63cc91 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -1203,6 +1203,7 @@ static int mtk_dsi_remove(struct platform_device *pdev)
> > }
> >
> > static const struct of_device_id mtk_dsi_of_match[] = {
> > + { .compatible = "mediatek,mt2701-dsi" },
> > { .compatible = "mediatek,mt8173-dsi" },
> > { },
> > };
>
> [...]
>
> >
> > static const struct of_device_id mtk_mipi_tx_match[] = {
> > + { .compatible = "mediatek,mt2701-mipi-tx",
> > + .data = &mt2701_mipitx_data },
> > { .compatible = "mediatek,mt8173-mipi-tx",
> > .data = &mt8173_mipitx_data },
> > {},
>
> I'm not sure if I missed some, but you should update the binding
> description for newly added bindings.
>
> Thanks a lot,
> Matthias
Oh, you are right. I thought there is already sent binding description
but actually no. I will update this part for newly added bindings.
Thanks for informing.
yt.shen
^ permalink raw reply
* [LINUX RFC v4 3/4] mtd: spi-nor: add stripe support
From: Cyrille Pitchen @ 2016-12-05 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DA6901612C71B84D91459DE817C418AE26E0C110@XAP-PVEXMBX01.xlnx.xilinx.com>
Hi Naga,
Le 05/12/2016 ? 08:02, Naga Sureshkumar Relli a ?crit :
> Hi Cyrille,
>
>>> Hi Cyrille,
>>>
>>>> I have not finished to review the whole series yet but here some
>>>> first
>>>> comments:
>>>
>>> Thanks for reviewing these patch series.
>>>
>>>>
>>>> Le 27/11/2016 ? 09:33, Naga Sureshkumar Relli a ?crit :
>>>>> This patch adds stripe support and it is needed for GQSPI parallel
>>>>> configuration mode by:
>>>>>
>>>>> - Adding required parameters like stripe and shift to spi_nor
>>>>> structure.
>>>>> - Initializing all added parameters in spi_nor_scan()
>>>>> - Updating read_sr() and read_fsr() for getting status from both
>>>>> flashes
>>>>> - Increasing page_size, sector_size, erase_size and toatal flash
>>>>> size as and when required.
>>>>> - Dividing address by 2
>>>>> - Updating spi->master->flags for qspi driver to change CS
>>>>>
>>>>> Signed-off-by: Naga Sureshkumar Relli <nagasure@xilinx.com>
>>>>> ---
>>>>> Changes for v4:
>>>>> - rename isparallel to stripe
>>>>> Changes for v3:
>>>>> - No change
>>>>> Changes for v2:
>>>>> - Splitted to separate MTD layer changes from SPI core changes
>>>>> ---
>>>>> drivers/mtd/spi-nor/spi-nor.c | 130
>>>> ++++++++++++++++++++++++++++++++----------
>>>>> include/linux/mtd/spi-nor.h | 2 +
>>>>> 2 files changed, 103 insertions(+), 29 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mtd/spi-nor/spi-nor.c
>>>>> b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..4252239 100644
>>>>> --- a/drivers/mtd/spi-nor/spi-nor.c
>>>>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>>>>> @@ -22,6 +22,7 @@
>>>>> #include <linux/of_platform.h>
>>>>> #include <linux/spi/flash.h>
>>>>> #include <linux/mtd/spi-nor.h>
>>>>> +#include <linux/spi/spi.h>
>>>>>
>>>>> /* Define max times to check status register before we give up. */
>>>>>
>>>>> @@ -89,15 +90,24 @@ static const struct flash_info
>>>>> *spi_nor_match_id(const char *name); static int read_sr(struct
>>>>> spi_nor *nor) {
>>>>> int ret;
>>>>> - u8 val;
>>>>> + u8 val[2];
>>>>>
>>>>> - ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val, 1);
>>>>> - if (ret < 0) {
>>>>> - pr_err("error %d reading SR\n", (int) ret);
>>>>> - return ret;
>>>>> + if (nor->stripe) {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 2);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading SR\n", (int) ret);
>>>>> + return ret;
>>>>> + }
>>>>> + val[0] |= val[1];
>>>> Why '|' rather than '&' ?
>>>> I guess because of the 'Write In Progress/Busy' bit: when called by
>>>> spi_nor_sr_ready(), you want to be sure that this 'BUSY' bit is
>>>> cleared on both memories.
>>>>
>>>> But what about when the Status Register is read for purpose other
>>>> than checking the state of the 'BUSY' bit?
>>>>
>>> Yes you are correct, I will change this.
>>>
>>>> What about SPI controllers supporting more than 2 memories in parallel?
>>>>
>>>> This solution might fit the ZynqMP controller but doesn't look so generic.
>>>>
>>>>> + } else {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDSR, &val[0], 1);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading SR\n", (int) ret);
>>>>> + return ret;
>>>>> + }
>>>>> }
>>>>>
>>>>> - return val;
>>>>> + return val[0];
>>>>> }
>>>>>
>>>>> /*
>>>>> @@ -108,15 +118,24 @@ static int read_sr(struct spi_nor *nor)
>>>>> static int read_fsr(struct spi_nor *nor) {
>>>>> int ret;
>>>>> - u8 val;
>>>>> + u8 val[2];
>>>>>
>>>>> - ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
>>>>> - if (ret < 0) {
>>>>> - pr_err("error %d reading FSR\n", ret);
>>>>> - return ret;
>>>>> + if (nor->stripe) {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 2);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading FSR\n", ret);
>>>>> + return ret;
>>>>> + }
>>>>> + val[0] &= val[1];
>>>> Same comment here: why '&' rather than '|'?
>>>> Surely because of the the 'READY' bit which should be set for both
>> memories.
>>> I will update this also.
>>>>
>>>>> + } else {
>>>>> + ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val[0], 1);
>>>>> + if (ret < 0) {
>>>>> + pr_err("error %d reading FSR\n", ret);
>>>>> + return ret;
>>>>> + }
>>>>> }
>>>>>
>>>>> - return val;
>>>>> + return val[0];
>>>>> }
>>>>>
>>>>> /*
>>>>> @@ -290,9 +309,16 @@ static int spi_nor_wait_till_ready(struct
>>>>> spi_nor
>>>> *nor)
>>>>> */
>>>>> static int erase_chip(struct spi_nor *nor) {
>>>>> + u32 ret;
>>>>> +
>>>>> dev_dbg(nor->dev, " %lldKiB\n", (long long)(nor->mtd.size >> 10));
>>>>>
>>>>> - return nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
>>>>> + ret = nor->write_reg(nor, SPINOR_OP_CHIP_ERASE, NULL, 0);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + return ret;
>>>>> +
>>>>
>>>> if (ret)
>>>> return ret;
>>>> else
>>>> return ret;
>>>>
>>>> This chunk should be removed, it doesn't ease the patch review ;)
>>> Ok, I will remove.
>>>>
>>>>> }
>>>>>
>>>>> static int spi_nor_lock_and_prep(struct spi_nor *nor, enum
>>>>> spi_nor_ops ops) @@ -349,7 +375,7 @@ static int
>>>>> spi_nor_erase_sector(struct spi_nor *nor, u32 addr) static int
>>>>> spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr) {
>>>>> struct spi_nor *nor = mtd_to_spi_nor(mtd);
>>>>> - u32 addr, len;
>>>>> + u32 addr, len, offset;
>>>>> uint32_t rem;
>>>>> int ret;
>>>>>
>>>>> @@ -399,9 +425,13 @@ static int spi_nor_erase(struct mtd_info *mtd,
>>>> struct erase_info *instr)
>>>>> /* "sector"-at-a-time erase */
>>>>> } else {
>>>>> while (len) {
>>>>> +
>>>>> write_enable(nor);
>>>>> + offset = addr;
>>>>> + if (nor->stripe)
>>>>> + offset /= 2;
>>>>
>>>> I guess this should be /= 4 for controllers supporting 4 memories in
>> parallel.
>>>> Shouldn't you use nor->shift and define shift as an unsigned int
>>>> instead of a bool?
>>>> offset >>= nor->shift;
>>>>
>>> Yes we can use this shift, I will update
>>>
>>>> Anyway, by tuning the address here in spi-nor.c rather than in the
>>>> SPI controller driver, you impose a model to support parallel
>>>> memories that might not be suited to other controllers.
>>>
>>> For this ZynqMP GQSPI controller parallel configuration, globally
>>> spi-nor should know about this stripe feature And based on that address
>> has to change.
>>> As I mentioned in cover letter, this controller in parallel configuration will
>> work with even addresses only.
>>> i.e. Before creating address format(m25p_addr2cmd) in mtd layer, spi-nor
>> should change that address based on stripe option.
>>>
>>> I am updating this offset based on stripe option, and stripe option will
>> update by reading dt property in nor_scan().
>>> So the controller which doesn't support, then the stripe will be zero.
>>> Or Can you please suggest any other way?
>>>
>>>>
>>>>>
>>>>> - ret = spi_nor_erase_sector(nor, addr);
>>>>> + ret = spi_nor_erase_sector(nor, offset);
>>>>> if (ret)
>>>>> goto erase_err;
>>>>>
>>>>> @@ -525,6 +555,8 @@ static int stm_lock(struct spi_nor *nor, loff_t
>>>>> ofs,
>>>> uint64_t len)
>>>>> bool use_top;
>>>>> int ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> status_old = read_sr(nor);
>>>>> if (status_old < 0)
>>>>> return status_old;
>>>>> @@ -610,6 +642,8 @@ static int stm_unlock(struct spi_nor *nor,
>>>>> loff_t ofs,
>>>> uint64_t len)
>>>>> bool use_top;
>>>>> int ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> status_old = read_sr(nor);
>>>>> if (status_old < 0)
>>>>> return status_old;
>>>>> @@ -709,6 +743,8 @@ static int spi_nor_lock(struct mtd_info *mtd,
>>>>> loff_t
>>>> ofs, uint64_t len)
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> ret = nor->flash_lock(nor, ofs, len);
>>>>>
>>>>> spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_UNLOCK); @@ -
>>>> 724,6 +760,8
>>>>> @@ static int spi_nor_unlock(struct mtd_info *mtd, loff_t ofs,
>>>>> uint64_t
>>>> len)
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> + ofs = ofs >> nor->shift;
>>>>> +
>>>>> ret = nor->flash_unlock(nor, ofs, len);
>>>>>
>>>>> spi_nor_unlock_and_unprep(nor, SPI_NOR_OPS_LOCK); @@ -
>>>> 1018,6 +1056,9
>>>>> @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
>>>>> u8 id[SPI_NOR_MAX_ID_LEN];
>>>>> const struct flash_info *info;
>>>>>
>>>>> + nor->spi->master->flags &= ~(SPI_MASTER_BOTH_CS |
>>>>> + SPI_MASTER_DATA_STRIPE);
>>>>> +
>>>>> tmp = nor->read_reg(nor, SPINOR_OP_RDID, id,
>>>> SPI_NOR_MAX_ID_LEN);
>>>>> if (tmp < 0) {
>>>>> dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
>>>> @@ -1041,6
>>>>> +1082,7 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
>>>>> +from,
>>>>> size_t len, {
>>>>> struct spi_nor *nor = mtd_to_spi_nor(mtd);
>>>>> int ret;
>>>>> + u32 offset = from;
>>>>>
>>>>> dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
>>>>>
>>>>> @@ -1049,7 +1091,13 @@ static int spi_nor_read(struct mtd_info *mtd,
>>>> loff_t from, size_t len,
>>>>> return ret;
>>>>>
>>>>> while (len) {
>>>>> - ret = nor->read(nor, from, len, buf);
>>>>> +
>>>>> + offset = from;
>>>>> +
>>>>> + if (nor->stripe)
>>>>> + offset /= 2;
>>>>> +
>>>>> + ret = nor->read(nor, offset, len, buf);
>>>>> if (ret == 0) {
>>>>> /* We shouldn't see 0-length reads */
>>>>> ret = -EIO;
>>>>> @@ -1161,6 +1209,7 @@ static int spi_nor_write(struct mtd_info *mtd,
>>>> loff_t to, size_t len,
>>>>> struct spi_nor *nor = mtd_to_spi_nor(mtd);
>>>>> size_t page_offset, page_remain, i;
>>>>> ssize_t ret;
>>>>> + u32 offset;
>>>>>
>>>>> dev_dbg(nor->dev, "to 0x%08x, len %zd\n", (u32)to, len);
>>>>>
>>>>> @@ -1178,9 +1227,13 @@ static int spi_nor_write(struct mtd_info
>>>>> *mtd,
>>>> loff_t to, size_t len,
>>>>> /* the size of data remaining on the first page */
>>>>> page_remain = min_t(size_t,
>>>>> nor->page_size - page_offset, len - i);
>>>>> + offset = (to + i);
>>>>> +
>>>>> + if (nor->stripe)
>>>>> + offset /= 2;
>>>>>
>>>>> write_enable(nor);
>>>>> - ret = nor->write(nor, to + i, page_remain, buf + i);
>>>>> + ret = nor->write(nor, (offset), page_remain, buf + i);
>>>>> if (ret < 0)
>>>>> goto write_err;
>>>>> written = ret;
>>>>> @@ -1302,22 +1355,22 @@ static int spi_nor_check(struct spi_nor
>>>>> *nor)
>>>>>
>>>>> int spi_nor_scan(struct spi_nor *nor, const char *name, enum
>>>>> read_mode mode) {
>>>>> - const struct flash_info *info = NULL;
>>>>> + struct flash_info *info = NULL;
>>>>
>>>> You should not remove the const and should not try to modify members
>>>> of *info.
>>>>
>>>>> struct device *dev = nor->dev;
>>>>> struct mtd_info *mtd = &nor->mtd;
>>>>> struct device_node *np = spi_nor_get_flash_node(nor);
>>>>> - int ret;
>>>>> - int i;
>>>>> + struct device_node *np_spi;
>>>>> + int ret, i, xlnx_qspi_mode;
>>>>>
>>>>> ret = spi_nor_check(nor);
>>>>> if (ret)
>>>>> return ret;
>>>>>
>>>>> if (name)
>>>>> - info = spi_nor_match_id(name);
>>>>> + info = (struct flash_info *)spi_nor_match_id(name);
>>>>> /* Try to auto-detect if chip name wasn't specified or not found */
>>>>> if (!info)
>>>>> - info = spi_nor_read_id(nor);
>>>>> + info = (struct flash_info *)spi_nor_read_id(nor);
>>>>> if (IS_ERR_OR_NULL(info))
>>>>> return -ENOENT;
>>>>>
>>>> Both spi_nor_match_id() and spi_nor_read_id(), when they succeed,
>>>> return a pointer to an entry of the spi_nor_ids[] array, which is
>>>> located in a read- only memory area.
>>>>
>>>> Since your patch doesn't remove the const attribute of the
>>>> spi_nor_ids[], I wonder whether it has been tested. I expect it not
>>>> to work on most architecture.
>>>>
>>>> Anyway spi_nor_ids[] should remain const. Let's take the case of
>>>> eXecution In Place (XIP) from an external memory: if spi_nor_ids[] is
>>>> const, it can be read directly from this external (read-only) memory
>>>> and we never need to copy the array in RAM, so we save some KB of
>> RAM.
>>>> This is just an example but I guess we can find other reasons to keep
>>>> this array const.
>>>>
>>>>> @@ -1341,7 +1394,7 @@ int spi_nor_scan(struct spi_nor *nor, const
>>>>> char
>>>> *name, enum read_mode mode)
>>>>> */
>>>>> dev_warn(dev, "found %s, expected %s\n",
>>>>> jinfo->name, info->name);
>>>>> - info = jinfo;
>>>>> + info = (struct flash_info *)jinfo;
>>>>> }
>>>>> }
>>>>>
>>>>> @@ -1370,6 +1423,27 @@ int spi_nor_scan(struct spi_nor *nor, const
>>>>> char
>>>> *name, enum read_mode mode)
>>>>> mtd->size = info->sector_size * info->n_sectors;
>>>>> mtd->_erase = spi_nor_erase;
>>>>> mtd->_read = spi_nor_read;
>>>>> +#ifdef CONFIG_OF
>>>>> + np_spi = of_get_next_parent(np);
>>>>> +
>>>>> + if (of_property_read_u32(np_spi, "xlnx,qspi-mode",
>>>>> + &xlnx_qspi_mode) < 0) {
>>>> This really looks controller specific so should not be placed in the
>>>> generic spi- nor.c file.
>>>
>>> Const is removed in info struct, because to update info members based
>> parallel configuration.
>>> As I mentioned above, for this parallel configuration, mtd and
>>> spi-nor should know the details like
>>> mtd->size, info->sectors, sector_size and page_size.
>>
>> You can tune the values of nor->mtd.size, nor->mtd.erasesize, nor-
>>> page_size or whatever member of nor/nor.mtd as needed without ever
>> modifying members of *info.
>>
>> If you modify *info then spi_nor_scan() is called a 2nd time to probe and
>> configure SPI memories of the same part but connected to another
>> controller, the values of the modified members in this *info would not be
>> those expected.
>> So *info and the spi_nor_ids[] array must remain const.
>>
>> The *info structure is not used outside spi_nor_scan(); none of
>> spi_nor_read(),
>> spi_nor_write() and spi_nor_erase() refers to *info hence every relevant
>> value can be set only nor or nor->mtd members.
>>
>>
>> Anyway, I think OR'ing or AND'ing values of memory registers depending on
>> the relevant bit we want to check is not the right solution.
>> If done in spi-nor.c, there would be a specific case for each memory register
>> we read, each register bit would have to be handled differently.
>>
>> spi-nor.c tries to support as much memory parts as possible, it deals with
>> many registers and bits: Status/Control registers, Quad Enable bits...
>>
>> If we start to OR or AND each of these register values to support the
>> stripping mode, spi-nor will become really hard to maintain.
>>
>> I don't know whether it could be done with the xilinx controller but I thought
>> about first configuring the two memories independently calling
>> spi_nor_scan() twice; one call for each memory.
>>
>> Then the xilinx driver could register only one struct mtd_info, overriding
>> mtd->_read() [and likely mtd->_write() and mtd->_erase() too] set by
>> spi_nor_scan() with a xilinx driver custom implementation so this driver
>> supports its controller stripping mode as it wants.
>>
>> Of course, this solution assumes that the SPI controller has one dedicated
>> chip-select line for each memory and not a single chip-select line shared by
>> both memories. The memories should be configured independently: you
>> can't assume multiple instances of the very same memory part always return
>> the exact same value when reading one of their register. Logical AND/OR is
>> not a generic solution, IMHO.
>>
>> If the xilinx controller has only one shared chip-select line then let's see
>> whether 2 GPIO lines could be used as independent chip-select lines.
>>
>>
> In parallel configuration, Physically we have two flashes but mtd will see as single flash memory (sum of both memories)
> If we call spi_nor_scan(), twice then read/write will override but nor->mtd.size, nor->mtd.erasesize, nor->page_size will remain same, I,e they will also override, they won't append.
> I tried calling spi_nor_scan() twice by some hacks but nor->mtd.size, nor->mtd.erasesize, nor->page_size are not changing
> Also the same issue we are getting for flash address, need to shift the address to work in this configuration.
> Also to tune nor->mtd.size, nor->mtd.erasesize, nor->page_size, we need to touch this spi-nor.c
>
> Please kindly suggest, if I am wrong.
>
What I've been suggesting is:
{
struct spi_nor *nor1, *nor2;
struct mtd_info *mtd;
enum read_mode mode = SPI_NOR_QUAD;
int err;
[...]
err = spi_nor_scan(nor1, NULL, mode);
if (err)
return err; /* or handle error properly. */
err = spi_nor_scan(nor2, NULL, mode);
if (err)
return err;
mtd = &nor1->mtd;
mtd->erasesize <<= 1;
mtd->size <<= 1;
mtd->writebufsize <<= 1;
nor1->page_size <<= 1;
/* tune all other relevant members of nor1/mtd. */
/* override relevant mtd hooks. */
mtd->_read = stripping_read;
mtd->_erase = stripping_erase;
mtd->_write = stripping_write;
mtd->_lock = ...;
mtd->_unlock = ...;
mtd->_is_lock = ...;
/* register a single mtd_info structure. */
err = mtd_device_register(mtd, NULL, 0);
if (err)
return err;
[...]
}
Best regards,
Cyrille
> Thanks,
> Naga Sureshkumar Relli
>
>> Best regards,
>>
>> Cyrille
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
^ permalink raw reply
* [PATCH v3 2/5] spi: armada-3700: Add support for the FIFO mode
From: Mark Brown @ 2016-12-05 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201102719.4291-3-romain.perier@free-electrons.com>
On Thu, Dec 01, 2016 at 11:27:16AM +0100, Romain Perier wrote:
> Changes in v3:
> - Don't enable the fifo mode based on the compatible string, we introduce
> a module parameter "pio_mode". By default this option is set to zero, so
> the fifo mode is enabled. Pass pio_mode=1 to the driver enables the PIO
> mode.
Why? If the hardware supports a more efficient mode of operation it
doesn't seem sensible not to use it.
> - int i;
> + int i, ret = 0;
Coding style - don't combine initialized and non-initalized variables on
one line.
> static int a3700_spi_transfer_one(struct spi_master *master,
> struct spi_device *spi,
> struct spi_transfer *xfer)
> {
> struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> - int ret = 0;
> + int ret;
>
> a3700_spi_transfer_setup(spi, xfer);
>
> @@ -505,6 +737,151 @@ static int a3700_spi_transfer_one(struct spi_master *master,
> return ret;
> }
This appears to be a random unrelated change, should probably be part of
the initial driver commit.
> +static int a3700_spi_fifo_transfer_one(struct spi_master *master,
> + struct spi_device *spi,
> + struct spi_transfer *xfer)
> +{
> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
> + int ret = 0, timeout = A3700_SPI_TIMEOUT;
> + unsigned int nbits = 0;
> + u32 val;
> +
> + a3700_spi_transfer_setup(spi, xfer);
> +
> + a3700_spi->tx_buf = xfer->tx_buf;
> + a3700_spi->rx_buf = xfer->rx_buf;
> + a3700_spi->buf_len = xfer->len;
> +
> + /* SPI transfer headers */
> + a3700_spi_header_set(a3700_spi);
> +
> + if (xfer->tx_buf)
> + nbits = xfer->tx_nbits;
> + else if (xfer->rx_buf)
> + nbits = xfer->rx_nbits;
> +
> + a3700_spi_pin_mode_set(a3700_spi, nbits);
> +
> + if (xfer->rx_buf) {
> + /* Set read data length */
> + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
> + a3700_spi->buf_len);
> + /* Start READ transfer */
> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> + val &= ~A3700_SPI_RW_EN;
> + val |= A3700_SPI_XFER_START;
> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> + } else if (xfer->tx_buf) {
> + /* Start Write transfer */
So this only supports single duplex transfers but there doesn't seem to
be anything that enforces this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161205/39205c21/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] USB: OHCI: nxp: remove useless extern declaration
From: Greg Kroah-Hartman @ 2016-12-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480735523-23950-4-git-send-email-csmanjuvijay@gmail.com>
On Sat, Dec 03, 2016 at 03:25:23AM +0000, csmanjuvijay at gmail.com wrote:
> From: Manjunath Goudar <csmanjuvijay@gmail.com>
>
> Remove usb_disabled() extern declaration as it is already declared
> as EXPORT_SYMBOL_GPL declaration.
And same thing again...
^ permalink raw reply
* [PATCH 2/3] serial: st-asc: Provide RTS functionality
From: Patrice Chotard @ 2016-12-05 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202141146.31281-2-lee.jones@linaro.org>
Hi Lee
On 12/02/2016 03:11 PM, Lee Jones wrote:
> Until this point, it has not been possible for serial applications
> to toggle the UART RTS line. This can be useful with certain
> configurations. For example, when using a Mezzanine on a Linaro
> 96board, RTS line is used to take the the on-board microcontroller
typo "the the on"
> in and out of reset.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/tty/serial/st-asc.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
> index 379e5bd..ce46898 100644
> --- a/drivers/tty/serial/st-asc.c
> +++ b/drivers/tty/serial/st-asc.c
> @@ -30,6 +30,7 @@
> #include <linux/of_platform.h>
> #include <linux/serial_core.h>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
>
> #define DRIVER_NAME "st-asc"
> #define ASC_SERIAL_NAME "ttyAS"
> @@ -38,6 +39,7 @@
>
> struct asc_port {
> struct uart_port port;
> + struct gpio_desc *rts;
> struct clk *clk;
> unsigned int hw_flow_control:1;
> unsigned int force_m1:1;
> @@ -381,12 +383,16 @@ static unsigned int asc_tx_empty(struct uart_port *port)
>
> static void asc_set_mctrl(struct uart_port *port, unsigned int mctrl)
> {
> + struct asc_port *ascport = to_asc_port(port);
> +
> /*
> * This routine is used for seting signals of: DTR, DCD, CTS/RTS
> * We use ASC's hardware for CTS/RTS, so don't need any for that.
> * Some boards have DTR and DCD implemented using PIO pins,
> * code to do this should be hooked in here.
> */
> +
> + gpiod_set_value(ascport->rts, mctrl & TIOCM_RTS);
> }
>
> static unsigned int asc_get_mctrl(struct uart_port *port)
> @@ -731,12 +737,20 @@ MODULE_DEVICE_TABLE(of, asc_match);
> static int asc_serial_probe(struct platform_device *pdev)
> {
> int ret;
> + struct device_node *np = pdev->dev.of_node;
> struct asc_port *ascport;
> + struct gpio_desc *gpiod;
>
> ascport = asc_of_get_asc_port(pdev);
> if (!ascport)
> return -ENODEV;
>
> + gpiod = devm_get_gpiod_from_child(&pdev->dev, "rts", &np->fwnode);
> + if (!IS_ERR(gpiod)) {
> + gpiod_direction_output(gpiod, 0);
> + ascport->rts = gpiod;
> + }
> +
> ret = asc_init_port(ascport, pdev);
> if (ret)
> return ret;
>
^ permalink raw reply
* [PATCH 3/3] USB: OHCI: nxp: remove useless extern declaration
From: Greg Kroah-Hartman @ 2016-12-05 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480735523-23950-4-git-send-email-csmanjuvijay@gmail.com>
On Sat, Dec 03, 2016 at 03:25:23AM +0000, csmanjuvijay at gmail.com wrote:
> From: Manjunath Goudar <csmanjuvijay@gmail.com>
>
> Remove usb_disabled() extern declaration as it is already declared
> as EXPORT_SYMBOL_GPL declaration.
merge this with your first patch please, it belongs with it.
^ permalink raw reply
* ILP32 for ARM64 - testing with lmbench
From: Catalin Marinas @ 2016-12-05 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0adfca97-1624-8eac-8149-da447525ad65@huawei.com>
On Mon, Dec 05, 2016 at 06:16:09PM +0800, Zhangjian (Bamvor) wrote:
> Do you have suggestion of next move of upstreaming ILP32?
I mentioned the steps a few time before. I'm pasting them again here:
1. Complete the review of the Linux patches and ABI (no merge yet)
2. Review the corresponding glibc patches (no merge yet)
3. Ask (Linaro, Cavium) for toolchain + filesystem (pre-built and more
than just busybox) to be able to reproduce the testing in ARM
4. More testing (LTP, trinity, performance regressions etc.)
5. Move the ILP32 PCS out of beta (based on the results from 4)
6. Check the market again to see if anyone still needs ILP32
7. Based on 6, decide whether to merge the kernel and glibc patches
What's not explicitly mentioned in step 4 is glibc testing. Point 5 is
ARM's responsibility (toolchain folk).
> There are already the test results of lmbench and specint. Do you they
> are ok or need more data to prove no regression?
I would need to reproduce the tests myself, see step 3.
> I have also noticed that there are ILP32 failures in glibc testsuite.
> Is it the only blocker for merge ILP32(in technology part)?
It's probably not the only blocker but I have to review the kernel
patches again to make sure. I'd also like to see whether the libc-alpha
community is ok with the glibc counterpart (but don't merge the patches
until the ABI is agreed on both sides).
On performance, I want to make sure there are no regressions on
AArch32/compat and AArch64/LP64.
--
Catalin
^ permalink raw reply
* [PATCH v5] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Alexandre Bailon @ 2016-12-05 14:13 UTC (permalink / raw)
To: linux-arm-kernel
Everytime the usb20 phy is enabled, there is a
"sleeping function called from invalid context" BUG.
clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
before to invoke the callback usb20_phy_clk_enable().
usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
which may sleep.
Move clk_get() to da8xx_register_usb20_phy_clk() and
replace clk_prepare_enable() by clk_enable().
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
---
arch/arm/mach-davinci/usb-da8xx.c | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
index b010e5f..f62f9c2 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -22,6 +22,8 @@
#define DA8XX_USB0_BASE 0x01e00000
#define DA8XX_USB1_BASE 0x01e25000
+static struct clk *usb20_clk;
+
static struct platform_device da8xx_usb_phy = {
.name = "da8xx-usb-phy",
.id = -1,
@@ -158,24 +160,16 @@ int __init da8xx_register_usb_refclkin(int rate)
static void usb20_phy_clk_enable(struct clk *clk)
{
- struct clk *usb20_clk;
int err;
u32 val;
u32 timeout = 500000; /* 500 msec */
val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
- usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
- if (IS_ERR(usb20_clk)) {
- pr_err("could not get usb20 clk: %ld\n", PTR_ERR(usb20_clk));
- return;
- }
-
/* The USB 2.O PLL requires that the USB 2.O PSC is enabled as well. */
- err = clk_prepare_enable(usb20_clk);
+ err = clk_enable(usb20_clk);
if (err) {
pr_err("failed to enable usb20 clk: %d\n", err);
- clk_put(usb20_clk);
return;
}
@@ -197,8 +191,7 @@ static void usb20_phy_clk_enable(struct clk *clk)
pr_err("Timeout waiting for USB 2.0 PHY clock good\n");
done:
- clk_disable_unprepare(usb20_clk);
- clk_put(usb20_clk);
+ clk_disable(usb20_clk);
}
static void usb20_phy_clk_disable(struct clk *clk)
@@ -285,11 +278,19 @@ static struct clk_lookup usb20_phy_clk_lookup =
int __init da8xx_register_usb20_phy_clk(bool use_usb_refclkin)
{
struct clk *parent;
- int ret = 0;
+ int ret;
+
+ usb20_clk = clk_get(&da8xx_usb20_dev.dev, "usb20");
+ ret = PTR_ERR_OR_ZERO(usb20_clk);
+ if (ret)
+ return ret;
parent = clk_get(NULL, use_usb_refclkin ? "usb_refclkin" : "pll0_aux");
- if (IS_ERR(parent))
- return PTR_ERR(parent);
+ ret = PTR_ERR_OR_ZERO(parent);
+ if (ret) {
+ clk_put(usb20_clk);
+ return ret;
+ }
usb20_phy_clk.parent = parent;
ret = clk_register(&usb20_phy_clk);
--
2.7.3
^ permalink raw reply related
* [PATCH v3 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Rob Herring @ 2016-12-05 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480420624-23544-2-git-send-email-bgolaszewski@baylibre.com>
On Tue, Nov 29, 2016 at 5:57 AM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
> 2 files changed, 75 insertions(+)
>
> diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
> index 711b9ad..d864f11 100644
> --- a/arch/arm/boot/dts/da850-lcdk.dts
> +++ b/arch/arm/boot/dts/da850-lcdk.dts
> @@ -50,6 +50,53 @@
> system-clock-frequency = <24576000>;
> };
> };
> +
> + vga_bridge {
s/_/-/
> + compatible = "dumb-vga-dac";
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_pins>;
Are these pins from the LCD controller? They should be part of the LCD
controller node.
Rob
^ permalink raw reply
* [PATCH v3 1/3] ARM: dts: vf610-zii-dev-rev-b: Remove leftover PWM pingroup
From: Andrey Smirnov @ 2016-12-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
Remove pwm0grp since it is:
a) Not referenced anywhere in the DTS file (unlike Tower board it
is based on, this board does not use/expose FTM0)
b) Configures PTB2 and PTB3 in a way that contradicts
pinctrl-mdio-mux
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v2:
- None
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index fa19cfd..2210811 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -677,15 +677,6 @@
>;
};
- pinctrl_pwm0: pwm0grp {
- fsl,pins = <
- VF610_PAD_PTB0__FTM0_CH0 0x1582
- VF610_PAD_PTB1__FTM0_CH1 0x1582
- VF610_PAD_PTB2__FTM0_CH2 0x1582
- VF610_PAD_PTB3__FTM0_CH3 0x1582
- >;
- };
-
pinctrl_qspi0: qspi0grp {
fsl,pins = <
VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
--
2.5.5
^ permalink raw reply related
* [PATCH v3 2/3] ARM: dts: vf610-zii-dev: Add .dts file for rev. C
From: Andrey Smirnov @ 2016-12-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480948716-17744-1-git-send-email-andrew.smirnov@gmail.com>
Add .dts file for rev. C of the board by factoring out commonalities
into a shared include file (vf610-zii-dev-rev-b-c.dtsi) and deriving
revision specific file from it (vf610-zii-dev-rev-b.dts and
vf610-zii-dev-reb-c.dts).
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
Changes since v2:
- Removed unnecessary "ethernet-phy-id0022.1550" string from
ethernet-phy at 0 node
- Correctecd IRQ_TYPE_EDGE_FALLING to IRQ_TYPE_LEVEL_LOW in
ethernet-phy at 0, since that's what KS8091 corresponding to
that node uses
- Changed PTB28's pinmux configuration to include a 47kOhm
pullup to pull aforementioned PHY IRQ line to unasserted
level by default
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 300 +----------------------
arch/arm/boot/dts/vf610-zii-dev-rev-c.dts | 394 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/vf610-zii-dev.dtsi | 383 +++++++++++++++++++++++++++++
4 files changed, 780 insertions(+), 300 deletions(-)
create mode 100644 arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
create mode 100644 arch/arm/boot/dts/vf610-zii-dev.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..9f0d2a1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -442,7 +442,8 @@ dtb-$(CONFIG_SOC_VF610) += \
vf610-cosmic.dtb \
vf610m4-cosmic.dtb \
vf610-twr.dtb \
- vf610-zii-dev-rev-b.dtb
+ vf610-zii-dev-rev-b.dtb \
+ vf610-zii-dev-rev-c.dtb
dtb-$(CONFIG_ARCH_MXS) += \
imx23-evk.dtb \
imx23-olinuxino.dtb \
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
index 2210811..c0fc3f2 100644
--- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
@@ -43,32 +43,12 @@
*/
/dts-v1/;
-#include "vf610.dtsi"
+#include "vf610-zii-dev.dtsi"
/ {
model = "ZII VF610 Development Board, Rev B";
compatible = "zii,vf610dev-b", "zii,vf610dev", "fsl,vf610";
- chosen {
- stdout-path = "serial0:115200n8";
- };
-
- memory {
- reg = <0x80000000 0x20000000>;
- };
-
- gpio-leds {
- compatible = "gpio-leds";
- pinctrl-0 = <&pinctrl_leds_debug>;
- pinctrl-names = "default";
-
- debug {
- label = "zii:green:debug1";
- gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "heartbeat";
- };
- };
-
mdio-mux {
compatible = "mdio-mux-gpio";
pinctrl-0 = <&pinctrl_mdio_mux>;
@@ -281,25 +261,6 @@
};
};
- reg_vcc_3v3_mcu: regulator-vcc-3v3-mcu {
- compatible = "regulator-fixed";
- regulator-name = "vcc_3v3_mcu";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- usb0_vbus: regulator-usb0-vbus {
- compatible = "regulator-fixed";
- pinctrl-0 = <&pinctrl_usb_vbus>;
- regulator-name = "usb_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- enable-active-high;
- regulator-always-on;
- regulator-boot-on;
- gpio = <&gpio0 6 0>;
- };
-
spi0 {
compatible = "spi-gpio";
pinctrl-0 = <&pinctrl_gpio_spi0>;
@@ -336,49 +297,6 @@
};
};
-&adc0 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_adc0_ad5>;
- vref-supply = <®_vcc_3v3_mcu>;
- status = "okay";
-};
-
-&edma0 {
- status = "okay";
-};
-
-&esdhc1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_esdhc1>;
- bus-width = <4>;
- status = "okay";
-};
-
-&fec0 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec0>;
- status = "okay";
-};
-
-&fec1 {
- phy-mode = "rmii";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_fec1>;
- status = "okay";
-
- fixed-link {
- speed = <100>;
- full-duplex;
- };
-
- mdio1: mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- status = "okay";
- };
-};
-
&i2c0 {
clock-frequency = <100000>;
pinctrl-names = "default";
@@ -403,33 +321,6 @@
interrupt-parent = <&gpio2>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
};
-
- lm75 at 48 {
- compatible = "national,lm75";
- reg = <0x48>;
- };
-
- at24c04 at 50 {
- compatible = "atmel,24c04";
- reg = <0x50>;
- };
-
- at24c04 at 52 {
- compatible = "atmel,24c04";
- reg = <0x52>;
- };
-
- ds1682 at 6b {
- compatible = "dallas,ds1682";
- reg = <0x6b>;
- };
-};
-
-&i2c1 {
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c1>;
- status = "okay";
};
&i2c2 {
@@ -499,120 +390,8 @@
};
};
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart0>;
- status = "okay";
-};
-
-&uart1 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart1>;
- status = "okay";
-};
-
-&uart2 {
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
- status = "okay";
-};
-
-&usbdev0 {
- disable-over-current;
- vbus-supply = <&usb0_vbus>;
- dr_mode = "host";
- status = "okay";
-};
-
-&usbh1 {
- disable-over-current;
- status = "okay";
-};
-
-&usbmisc0 {
- status = "okay";
-};
-
-&usbmisc1 {
- status = "okay";
-};
-
-&usbphy0 {
- status = "okay";
-};
-
-&usbphy1 {
- status = "okay";
-};
&iomuxc {
- pinctrl_adc0_ad5: adc0ad5grp {
- fsl,pins = <
- VF610_PAD_PTC30__ADC0_SE5 0x00a1
- >;
- };
-
- pinctrl_dspi0: dspi0grp {
- fsl,pins = <
- VF610_PAD_PTB18__DSPI0_CS1 0x1182
- VF610_PAD_PTB19__DSPI0_CS0 0x1182
- VF610_PAD_PTB20__DSPI0_SIN 0x1181
- VF610_PAD_PTB21__DSPI0_SOUT 0x1182
- VF610_PAD_PTB22__DSPI0_SCK 0x1182
- >;
- };
-
- pinctrl_dspi2: dspi2grp {
- fsl,pins = <
- VF610_PAD_PTD31__DSPI2_CS1 0x1182
- VF610_PAD_PTD30__DSPI2_CS0 0x1182
- VF610_PAD_PTD29__DSPI2_SIN 0x1181
- VF610_PAD_PTD28__DSPI2_SOUT 0x1182
- VF610_PAD_PTD27__DSPI2_SCK 0x1182
- >;
- };
-
- pinctrl_esdhc1: esdhc1grp {
- fsl,pins = <
- VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
- VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
- VF610_PAD_PTA26__ESDHC1_DAT0 0x31ef
- VF610_PAD_PTA27__ESDHC1_DAT1 0x31ef
- VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
- VF610_PAD_PTA29__ESDHC1_DAT3 0x31ef
- VF610_PAD_PTA7__GPIO_134 0x219d
- >;
- };
-
- pinctrl_fec0: fec0grp {
- fsl,pins = <
- VF610_PAD_PTC0__ENET_RMII0_MDC 0x30d2
- VF610_PAD_PTC1__ENET_RMII0_MDIO 0x30d3
- VF610_PAD_PTC2__ENET_RMII0_CRS 0x30d1
- VF610_PAD_PTC3__ENET_RMII0_RXD1 0x30d1
- VF610_PAD_PTC4__ENET_RMII0_RXD0 0x30d1
- VF610_PAD_PTC5__ENET_RMII0_RXER 0x30d1
- VF610_PAD_PTC6__ENET_RMII0_TXD1 0x30d2
- VF610_PAD_PTC7__ENET_RMII0_TXD0 0x30d2
- VF610_PAD_PTC8__ENET_RMII0_TXEN 0x30d2
- >;
- };
-
- pinctrl_fec1: fec1grp {
- fsl,pins = <
- VF610_PAD_PTA6__RMII_CLKIN 0x30d1
- VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2
- VF610_PAD_PTC10__ENET_RMII1_MDIO 0x30d3
- VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1
- VF610_PAD_PTC12__ENET_RMII1_RXD1 0x30d1
- VF610_PAD_PTC13__ENET_RMII1_RXD0 0x30d1
- VF610_PAD_PTC14__ENET_RMII1_RXER 0x30d1
- VF610_PAD_PTC15__ENET_RMII1_TXD1 0x30d2
- VF610_PAD_PTC16__ENET_RMII1_TXD0 0x30d2
- VF610_PAD_PTC17__ENET_RMII1_TXEN 0x30d2
- >;
- };
-
pinctrl_gpio_e6185_eeprom_sel: pinctrl-gpio-e6185-eeprom-spi0 {
fsl,pins = <
VF610_PAD_PTE27__GPIO_132 0x33e2
@@ -629,39 +408,6 @@
>;
};
- pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
- fsl,pins = <
- VF610_PAD_PTE14__GPIO_119 0x31c2
- >;
- };
-
- pinctrl_i2c0: i2c0grp {
- fsl,pins = <
- VF610_PAD_PTB14__I2C0_SCL 0x37ff
- VF610_PAD_PTB15__I2C0_SDA 0x37ff
- >;
- };
-
- pinctrl_i2c1: i2c1grp {
- fsl,pins = <
- VF610_PAD_PTB16__I2C1_SCL 0x37ff
- VF610_PAD_PTB17__I2C1_SDA 0x37ff
- >;
- };
-
- pinctrl_i2c2: i2c2grp {
- fsl,pins = <
- VF610_PAD_PTA22__I2C2_SCL 0x37ff
- VF610_PAD_PTA23__I2C2_SDA 0x37ff
- >;
- };
-
- pinctrl_leds_debug: pinctrl-leds-debug {
- fsl,pins = <
- VF610_PAD_PTD20__GPIO_74 0x31c2
- >;
- };
-
pinctrl_mdio_mux: pinctrl-mdio-mux {
fsl,pins = <
VF610_PAD_PTA18__GPIO_8 0x31c2
@@ -676,48 +422,4 @@
VF610_PAD_PTB28__GPIO_98 0x219d
>;
};
-
- pinctrl_qspi0: qspi0grp {
- fsl,pins = <
- VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
- VF610_PAD_PTD8__QSPI0_B_CS0 0x31ff
- VF610_PAD_PTD9__QSPI0_B_DATA3 0x31c3
- VF610_PAD_PTD10__QSPI0_B_DATA2 0x31c3
- VF610_PAD_PTD11__QSPI0_B_DATA1 0x31c3
- VF610_PAD_PTD12__QSPI0_B_DATA0 0x31c3
- >;
- };
-
- pinctrl_uart0: uart0grp {
- fsl,pins = <
- VF610_PAD_PTB10__UART0_TX 0x21a2
- VF610_PAD_PTB11__UART0_RX 0x21a1
- >;
- };
-
- pinctrl_uart1: uart1grp {
- fsl,pins = <
- VF610_PAD_PTB23__UART1_TX 0x21a2
- VF610_PAD_PTB24__UART1_RX 0x21a1
- >;
- };
-
- pinctrl_uart2: uart2grp {
- fsl,pins = <
- VF610_PAD_PTD0__UART2_TX 0x21a2
- VF610_PAD_PTD1__UART2_RX 0x21a1
- >;
- };
-
- pinctrl_usb_vbus: pinctrl-usb-vbus {
- fsl,pins = <
- VF610_PAD_PTA16__GPIO_6 0x31c2
- >;
- };
-
- pinctrl_usb0_host: usb0-host-grp {
- fsl,pins = <
- VF610_PAD_PTD6__GPIO_85 0x0062
- >;
- };
};
diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
new file mode 100644
index 0000000..4d38f41
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev-rev-c.dts
@@ -0,0 +1,394 @@
+/*
+ * Copyright (C) 2015, 2016 Zodiac Inflight Innovations
+ *
+ * Based on an original 'vf610-twr.dts' which is Copyright 2015,
+ * Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "vf610-zii-dev.dtsi"
+
+/ {
+ model = "ZII VF610 Development Board, Rev C";
+ compatible = "zii,vf610dev-c", "zii,vf610dev", "fsl,vf610";
+
+ mdio-mux {
+ compatible = "mdio-mux-gpio";
+ pinctrl-0 = <&pinctrl_mdio_mux>;
+ pinctrl-names = "default";
+ gpios = <&gpio0 8 GPIO_ACTIVE_HIGH
+ &gpio0 9 GPIO_ACTIVE_HIGH
+ &gpio0 25 GPIO_ACTIVE_HIGH>;
+ mdio-parent-bus = <&mdio1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio_mux_1: mdio at 1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0: switch0 at 0 {
+ compatible = "marvell,mv88e6190";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&fec1>;
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan4";
+ };
+
+ switch0port10: port at 10 {
+ reg = <10>;
+ label = "dsa";
+ phy-mode = "xgmii";
+ link = <&switch1port10>;
+ };
+ };
+ };
+ };
+
+ mdio_mux_2: mdio at 2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch1: switch1 at 0 {
+ compatible = "marvell,mv88e6190";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ dsa,member = <0 1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 1 {
+ reg = <1>;
+ label = "lan5";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan6";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan7";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan8";
+ };
+
+
+ switch1port10: port at 10 {
+ reg = <10>;
+ label = "dsa";
+ phy-mode = "xgmii";
+ link = <&switch0port10>;
+ };
+ };
+ };
+ };
+
+ mdio_mux_4: mdio at 4 {
+ reg = <4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&dspi0 {
+ bus-num = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dspi0>;
+ status = "okay";
+ spi-num-chipselects = <2>;
+
+ m25p128 at 0 {
+ compatible = "m25p128", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+&i2c0 {
+ /*
+ * U712
+ *
+ * Exposed signals:
+ * P1 - WE2_CMD
+ * P2 - WE2_CLK
+ */
+ gpio5: pca9557 at 18 {
+ compatible = "nxp,pca9557";
+ reg = <0x18>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ /*
+ * U121
+ *
+ * Exposed signals:
+ * I/O0 - ENET_SWR_EN
+ * I/O1 - ESW1_RESETn
+ * I/O2 - ARINC_RESET
+ * I/O3 - DD1_IO_RESET
+ * I/O4 - ESW2_RESETn
+ * I/O5 - ESW3_RESETn
+ * I/O6 - ESW4_RESETn
+ * I/O8 - TP909
+ * I/O9 - FEM_SEL
+ * I/O10 - WIFI_RESETn
+ * I/O11 - PHY_RSTn
+ * I/O12 - OPT1_SD
+ * I/O13 - OPT2_SD
+ * I/O14 - OPT1_TX_DIS
+ * I/O15 - OPT2_TX_DIS
+ */
+ gpio6: sx1503 at 20 {
+ compatible = "semtech,sx1503q";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sx1503_20>;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ reg = <0x20>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
+ gpio-controller;
+ interrupt-controller;
+
+ enet_swr_en {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "enet-swr-en";
+ };
+ };
+
+ /*
+ * U715
+ *
+ * Exposed signals:
+ * IO0 - WE1_CLK
+ * IO1 - WE1_CMD
+ */
+ gpio7: pca9554 at 22 {
+ compatible = "nxp,pca9554";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ };
+};
+
+&i2c1 {
+ at24mac602 at 00 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ read-only;
+ };
+};
+
+&i2c2 {
+ tca9548 at 70 {
+ compatible = "nxp,pca9548";
+ pinctrl-0 = <&pinctrl_i2c_mux_reset>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ sfp2: at24c04 at 50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ sfp3: at24c04 at 50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ };
+ };
+
+ i2c at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ };
+ };
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&gpio0 {
+ eth0_intrp {
+ gpio-hog;
+ gpios = <23 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "sx1503-irq";
+ };
+};
+
+&gpio3 {
+ eth0_intrp {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "eth0-intrp";
+ };
+};
+
+&fec0 {
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ ethernet-phy at 0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec0_phy_int>;
+
+ interrupt-parent = <&gpio3>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ reg = <0>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctr_atzb_rf_233: pinctrl-atzb-rf-233 {
+ fsl,pins = <
+ VF610_PAD_PTB2__GPIO_24 0x31c2
+ VF610_PAD_PTE27__GPIO_132 0x33e2
+ >;
+ };
+
+
+ pinctrl_sx1503_20: pinctrl-sx1503-20 {
+ fsl,pins = <
+ VF610_PAD_PTB1__GPIO_23 0x219d
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ VF610_PAD_PTA20__UART3_TX 0x21a2
+ VF610_PAD_PTA21__UART3_RX 0x21a1
+ >;
+ };
+
+ pinctrl_mdio_mux: pinctrl-mdio-mux {
+ fsl,pins = <
+ VF610_PAD_PTA18__GPIO_8 0x31c2
+ VF610_PAD_PTA19__GPIO_9 0x31c2
+ VF610_PAD_PTB3__GPIO_25 0x31c2
+ >;
+ };
+
+ pinctrl_fec0_phy_int: pinctrl-fec0-phy-int {
+ fsl,pins = <
+ VF610_PAD_PTB28__GPIO_98 0x219d
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/vf610-zii-dev.dtsi b/arch/arm/boot/dts/vf610-zii-dev.dtsi
new file mode 100644
index 0000000..9f5e2e7
--- /dev/null
+++ b/arch/arm/boot/dts/vf610-zii-dev.dtsi
@@ -0,0 +1,383 @@
+/*
+ * Copyright (C) 2015, 2016 Zodiac Inflight Innovations
+ *
+ * Based on an original 'vf610-twr.dts' which is Copyright 2015,
+ * Freescale Semiconductor, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+n * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "vf610.dtsi"
+
+/ {
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pinctrl_leds_debug>;
+ pinctrl-names = "default";
+
+ debug {
+ label = "zii:green:debug1";
+ gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ reg_vcc_3v3_mcu: regulator-vcc-3v3-mcu {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3_mcu";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ usb0_vbus: regulator-usb0-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-0 = <&pinctrl_usb_vbus>;
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio0 6 0>;
+ };
+};
+
+&adc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0_ad5>;
+ vref-supply = <®_vcc_3v3_mcu>;
+ status = "okay";
+};
+
+&edma0 {
+ status = "okay";
+};
+
+&esdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_esdhc1>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&fec0 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec0>;
+ status = "okay";
+};
+
+&fec1 {
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ status = "okay";
+
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+
+ mdio1: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+ };
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c0>;
+ pinctrl-1 = <&pinctrl_i2c0_gpio>;
+ scl-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ sda-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+
+ lm75 at 48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+
+ at24c04 at 50 {
+ compatible = "atmel,24c04";
+ reg = <0x50>;
+ };
+
+ at24c04 at 52 {
+ compatible = "atmel,24c04";
+ reg = <0x52>;
+ };
+
+ ds1682 at 6b {
+ compatible = "dallas,ds1682";
+ reg = <0x6b>;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart0>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usbdev0 {
+ disable-over-current;
+ vbus-supply = <&usb0_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usbh1 {
+ disable-over-current;
+ status = "okay";
+};
+
+&usbmisc0 {
+ status = "okay";
+};
+
+&usbmisc1 {
+ status = "okay";
+};
+
+&usbphy0 {
+ status = "okay";
+};
+
+&usbphy1 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_adc0_ad5: adc0ad5grp {
+ fsl,pins = <
+ VF610_PAD_PTC30__ADC0_SE5 0x00a1
+ >;
+ };
+
+ pinctrl_dspi0: dspi0grp {
+ fsl,pins = <
+ VF610_PAD_PTB18__DSPI0_CS1 0x1182
+ VF610_PAD_PTB19__DSPI0_CS0 0x1182
+ VF610_PAD_PTB20__DSPI0_SIN 0x1181
+ VF610_PAD_PTB21__DSPI0_SOUT 0x1182
+ VF610_PAD_PTB22__DSPI0_SCK 0x1182
+ >;
+ };
+
+ pinctrl_dspi2: dspi2grp {
+ fsl,pins = <
+ VF610_PAD_PTD31__DSPI2_CS1 0x1182
+ VF610_PAD_PTD30__DSPI2_CS0 0x1182
+ VF610_PAD_PTD29__DSPI2_SIN 0x1181
+ VF610_PAD_PTD28__DSPI2_SOUT 0x1182
+ VF610_PAD_PTD27__DSPI2_SCK 0x1182
+ >;
+ };
+
+ pinctrl_esdhc1: esdhc1grp {
+ fsl,pins = <
+ VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
+ VF610_PAD_PTA25__ESDHC1_CMD 0x31ef
+ VF610_PAD_PTA26__ESDHC1_DAT0 0x31ef
+ VF610_PAD_PTA27__ESDHC1_DAT1 0x31ef
+ VF610_PAD_PTA28__ESDHC1_DATA2 0x31ef
+ VF610_PAD_PTA29__ESDHC1_DAT3 0x31ef
+ VF610_PAD_PTA7__GPIO_134 0x219d
+ >;
+ };
+
+ pinctrl_fec0: fec0grp {
+ fsl,pins = <
+ VF610_PAD_PTC0__ENET_RMII0_MDC 0x30d2
+ VF610_PAD_PTC1__ENET_RMII0_MDIO 0x30d3
+ VF610_PAD_PTC2__ENET_RMII0_CRS 0x30d1
+ VF610_PAD_PTC3__ENET_RMII0_RXD1 0x30d1
+ VF610_PAD_PTC4__ENET_RMII0_RXD0 0x30d1
+ VF610_PAD_PTC5__ENET_RMII0_RXER 0x30d1
+ VF610_PAD_PTC6__ENET_RMII0_TXD1 0x30d2
+ VF610_PAD_PTC7__ENET_RMII0_TXD0 0x30d2
+ VF610_PAD_PTC8__ENET_RMII0_TXEN 0x30d2
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ VF610_PAD_PTA6__RMII_CLKIN 0x30d1
+ VF610_PAD_PTC9__ENET_RMII1_MDC 0x30d2
+ VF610_PAD_PTC10__ENET_RMII1_MDIO 0x30d3
+ VF610_PAD_PTC11__ENET_RMII1_CRS 0x30d1
+ VF610_PAD_PTC12__ENET_RMII1_RXD1 0x30d1
+ VF610_PAD_PTC13__ENET_RMII1_RXD0 0x30d1
+ VF610_PAD_PTC14__ENET_RMII1_RXER 0x30d1
+ VF610_PAD_PTC15__ENET_RMII1_TXD1 0x30d2
+ VF610_PAD_PTC16__ENET_RMII1_TXD0 0x30d2
+ VF610_PAD_PTC17__ENET_RMII1_TXEN 0x30d2
+ >;
+ };
+
+ pinctrl_gpio_spi0: pinctrl-gpio-spi0 {
+ fsl,pins = <
+ VF610_PAD_PTB22__GPIO_44 0x33e2
+ VF610_PAD_PTB21__GPIO_43 0x33e2
+ VF610_PAD_PTB20__GPIO_42 0x33e1
+ VF610_PAD_PTB19__GPIO_41 0x33e2
+ VF610_PAD_PTB18__GPIO_40 0x33e2
+ >;
+ };
+
+ pinctrl_i2c_mux_reset: pinctrl-i2c-mux-reset {
+ fsl,pins = <
+ VF610_PAD_PTE14__GPIO_119 0x31c2
+ >;
+ };
+
+ pinctrl_i2c0: i2c0grp {
+ fsl,pins = <
+ VF610_PAD_PTB14__I2C0_SCL 0x37ff
+ VF610_PAD_PTB15__I2C0_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_i2c0_gpio: i2c0grp-gpio {
+ fsl,pins = <
+ VF610_PAD_PTB14__GPIO_36 0x31c2
+ VF610_PAD_PTB15__GPIO_37 0x31c2
+ >;
+ };
+
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ VF610_PAD_PTB16__I2C1_SCL 0x37ff
+ VF610_PAD_PTB17__I2C1_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ VF610_PAD_PTA22__I2C2_SCL 0x37ff
+ VF610_PAD_PTA23__I2C2_SDA 0x37ff
+ >;
+ };
+
+ pinctrl_leds_debug: pinctrl-leds-debug {
+ fsl,pins = <
+ VF610_PAD_PTD20__GPIO_74 0x31c2
+ >;
+ };
+
+ pinctrl_qspi0: qspi0grp {
+ fsl,pins = <
+ VF610_PAD_PTD7__QSPI0_B_QSCK 0x31c3
+ VF610_PAD_PTD8__QSPI0_B_CS0 0x31ff
+ VF610_PAD_PTD9__QSPI0_B_DATA3 0x31c3
+ VF610_PAD_PTD10__QSPI0_B_DATA2 0x31c3
+ VF610_PAD_PTD11__QSPI0_B_DATA1 0x31c3
+ VF610_PAD_PTD12__QSPI0_B_DATA0 0x31c3
+ >;
+ };
+
+ pinctrl_uart0: uart0grp {
+ fsl,pins = <
+ VF610_PAD_PTB10__UART0_TX 0x21a2
+ VF610_PAD_PTB11__UART0_RX 0x21a1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ VF610_PAD_PTB23__UART1_TX 0x21a2
+ VF610_PAD_PTB24__UART1_RX 0x21a1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ VF610_PAD_PTD0__UART2_TX 0x21a2
+ VF610_PAD_PTD1__UART2_RX 0x21a1
+ >;
+ };
+
+ pinctrl_usb_vbus: pinctrl-usb-vbus {
+ fsl,pins = <
+ VF610_PAD_PTA16__GPIO_6 0x31c2
+ >;
+ };
+
+ pinctrl_usb0_host: usb0-host-grp {
+ fsl,pins = <
+ VF610_PAD_PTD6__GPIO_85 0x0062
+ >;
+ };
+};
--
2.5.5
^ 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