* [PATCH 3/7] ARM: DT: tegra114: add APB DMA controller DT entry
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
NVIDIA's Tegra114 has 32 channels APB DMA controller. Add DT entry for
APB DMA controllers and make it compatible with "nvidia,tegra114-apbdma".
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 9ce1a68..74f6a77 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -37,6 +37,43 @@
reg = <0x6000c004 0x14c>;
};
+ apbdma: dma {
+ compatible = "nvidia,tegra114-apbdma";
+ reg = <0x6000a000 0x1400>;
+ interrupts = <0 104 0x04
+ 0 105 0x04
+ 0 106 0x04
+ 0 107 0x04
+ 0 108 0x04
+ 0 109 0x04
+ 0 110 0x04
+ 0 111 0x04
+ 0 112 0x04
+ 0 113 0x04
+ 0 114 0x04
+ 0 115 0x04
+ 0 116 0x04
+ 0 117 0x04
+ 0 118 0x04
+ 0 119 0x04
+ 0 128 0x04
+ 0 129 0x04
+ 0 130 0x04
+ 0 131 0x04
+ 0 132 0x04
+ 0 133 0x04
+ 0 134 0x04
+ 0 135 0x04
+ 0 136 0x04
+ 0 137 0x04
+ 0 138 0x04
+ 0 139 0x04
+ 0 140 0x04
+ 0 141 0x04
+ 0 142 0x04
+ 0 143 0x04>;
+ };
+
gpio: gpio {
compatible = "nvidia,tegra114-gpio", "nvidia,tegra30-gpio";
reg = <0x6000d000 0x1000>;
--
1.7.1.1
^ permalink raw reply related
* [PATCH 4/7] ARM: DT: tegra114: add pinmux DT entry
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
Add DT entry for pinmux and drive configuration addresses.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 74f6a77..210b4a7 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -91,6 +91,12 @@
interrupt-controller;
};
+ pinmux: pinmux {
+ compatible = "nvidia,tegra114-pinmux";
+ reg = <0x70000868 0x148 /* Pad control registers */
+ 0x70003000 0x40c>; /* Mux registers */
+ };
+
serial at 70006000 {
compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
reg = <0x70006000 0x40>;
--
1.7.1.1
^ permalink raw reply related
* [PATCH 5/7] ARM: DT: tegra114: Add i2c controller DT entry
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
NVIDIA's Tegra114 has 5 i2c controllers. These controllers have
additional feature/configurations to make it functional over
Tegra30's i2c controller driver.
Add DT entry for i2c controllers and make it compatible with
"nvidia,tegra114-i2c".
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 45 +++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 210b4a7..74d18b2 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -129,6 +129,51 @@
status = "disabled";
};
+ i2c at 7000c000 {
+ compatible = "nvidia,tegra114-i2c";
+ reg = <0x7000c000 0x100>;
+ interrupts = <0 38 0x04>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c at 7000c400 {
+ compatible = "nvidia,tegra114-i2c";
+ reg = <0x7000c400 0x100>;
+ interrupts = <0 84 0x04>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c at 7000c500 {
+ compatible = "nvidia,tegra114-i2c";
+ reg = <0x7000c500 0x100>;
+ interrupts = <0 92 0x04>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c at 7000c700 {
+ compatible = "nvidia,tegra114-i2c";
+ reg = <0x7000c700 0x100>;
+ interrupts = <0 120 0x04>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c at 7000d000 {
+ compatible = "nvidia,tegra114-i2c";
+ reg = <0x7000d000 0x100>;
+ interrupts = <0 53 0x04>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
rtc {
compatible = "nvidia,tegra114-rtc", "nvidia,tegra20-rtc";
reg = <0x7000e000 0x100>;
--
1.7.1.1
^ permalink raw reply related
* [PATCH 6/7] ARM: DT: tegra114:add aliases and DMA requestor for serial controller
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
Add APB DMA requestor and serial aliases for serial controller.
There will be two serial driver i.e. 8250 based simple serial driver
and APB DMA based serial driver for higher baudrate and performace.
The simple serial driver get enabled with compatible nvidia,tegra20-uart
and APB DMA based driver will get enabled with compatible
nvidia,tegra30-hsuart.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 27 +++++++++++++++++++++++----
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 74d18b2..17fd061 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -4,6 +4,13 @@
compatible = "nvidia,tegra114";
interrupt-parent = <&gic>;
+ aliases {
+ serial0 = &uarta;
+ serial1 = &uartb;
+ serial2 = &uartc;
+ serial3 = &uartd;
+ };
+
gic: interrupt-controller {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
@@ -97,35 +104,47 @@
0x70003000 0x40c>; /* Mux registers */
};
- serial at 70006000 {
+ /*
+ * There are two serial driver i.e. 8250 based simple serial
+ * driver and APB DMA based serial driver for higher baudrate
+ * and performace. To enable the 8250 based driver, the compatible
+ * is "nvidia,tegra30-uart", "nvidia,tegra20-uart" and to enable
+ * the APB DMA based serial driver, the comptible is
+ * "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
+ */
+ uarta: serial at 70006000 {
compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
reg = <0x70006000 0x40>;
reg-shift = <2>;
interrupts = <0 36 0x04>;
+ nvidia,dma-request-selector = <&apbdma 8>;
status = "disabled";
};
- serial at 70006040 {
+ uartb: serial at 70006040 {
compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
reg = <0x70006040 0x40>;
reg-shift = <2>;
interrupts = <0 37 0x04>;
+ nvidia,dma-request-selector = <&apbdma 9>;
status = "disabled";
};
- serial at 70006200 {
+ uartc: serial at 70006200 {
compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
reg = <0x70006200 0x100>;
reg-shift = <2>;
interrupts = <0 46 0x04>;
+ nvidia,dma-request-selector = <&apbdma 10>;
status = "disabled";
};
- serial at 70006300 {
+ uartd: serial at 70006300 {
compatible = "nvidia,tegra114-uart", "nvidia,tegra20-uart";
reg = <0x70006300 0x100>;
reg-shift = <2>;
interrupts = <0 90 0x04>;
+ nvidia,dma-request-selector = <&apbdma 19>;
status = "disabled";
};
--
1.7.1.1
^ permalink raw reply related
* [PATCH 7/7] ARM: DT: tegra114: add KBC controller DT entry
From: Laxman Dewangan @ 2013-01-29 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-1-git-send-email-ldewangan@nvidia.com>
NVIDIA's Tegra114 SoCs have the matrix keyboard controller which
supports 11x8 type of matrix. The number of rows and columns
are configurable.
Add DT entry for KBC controller.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
arch/arm/boot/dts/tegra114.dtsi | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 17fd061..73a49f5 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -199,6 +199,13 @@
interrupts = <0 2 0x04>;
};
+ kbc {
+ compatible = "nvidia,tegra20-kbc";
+ reg = <0x7000e200 0x100>;
+ interrupts = <0 85 0x04>;
+ status = "disabled";
+ };
+
pmc {
compatible = "nvidia,tegra114-pmc", "nvidia,tegra30-pmc";
reg = <0x7000e400 0x400>;
--
1.7.1.1
^ permalink raw reply related
* [v3 1/1] ARM: dma-mapping: Set arm_dma_set_mask() for iommu->set_dma_mask()
From: Hiroshi Doyu @ 2013-01-29 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107C4DE.7060607@samsung.com>
struct dma_map_ops iommu_ops doesn't have ->set_dma_mask, which causes
crash when dma_set_mask() is called from some driver.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/mm/dma-mapping.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..5dfc71f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1730,6 +1730,8 @@ struct dma_map_ops iommu_ops = {
.unmap_sg = arm_iommu_unmap_sg,
.sync_sg_for_cpu = arm_iommu_sync_sg_for_cpu,
.sync_sg_for_device = arm_iommu_sync_sg_for_device,
+
+ .set_dma_mask = arm_dma_set_mask,
};
struct dma_map_ops iommu_coherent_ops = {
@@ -1743,6 +1745,8 @@ struct dma_map_ops iommu_coherent_ops = {
.map_sg = arm_coherent_iommu_map_sg,
.unmap_sg = arm_coherent_iommu_unmap_sg,
+
+ .set_dma_mask = arm_dma_set_mask,
};
/**
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm: fix returning wrong CALLER_ADDRx
From: Dave Martin @ 2013-01-29 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357888690-24012-1-git-send-email-kpark3469@gmail.com>
On Fri, Jan 11, 2013 at 04:18:10PM +0900, Keun-O Park wrote:
> From: sahara <keun-o.park@windriver.com>
>
> This makes return_address return correct value for ftrace feature.
> unwind_frame does not update frame->lr but frame->pc for backtrace.
> And, the initialization for data.addr was missing so that wrong value
> returned when unwind_frame failed.
>
> Signed-off-by: sahara <keun-o.park@windriver.com>
Reviewed-by: Dave Martin <dave.martin@linaro.org>
This is the same as a patch I previously posted:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/129381.html
...except for the initialisation of data.addr to NULL, which is needed
in order to prevent a garbage pointer being returned in the case where
the unwinder fails to unwind a frame before the required level
is reached.
Cheers
---Dave
> ---
> arch/arm/kernel/return_address.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
> index 8085417..fafedd8 100644
> --- a/arch/arm/kernel/return_address.c
> +++ b/arch/arm/kernel/return_address.c
> @@ -26,7 +26,7 @@ static int save_return_addr(struct stackframe *frame, void *d)
> struct return_address_data *data = d;
>
> if (!data->level) {
> - data->addr = (void *)frame->lr;
> + data->addr = (void *)frame->pc;
>
> return 1;
> } else {
> @@ -41,7 +41,8 @@ void *return_address(unsigned int level)
> struct stackframe frame;
> register unsigned long current_sp asm ("sp");
>
> - data.level = level + 1;
> + data.level = level + 2;
> + data.addr = NULL;
>
> frame.fp = (unsigned long)__builtin_frame_address(0);
> frame.sp = current_sp;
> --
> 1.7.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 5/5] ARM: mach-omap2: apply the errata at run time rather
From: Sergei Shtylyov @ 2013-01-29 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129101711.GA23311@bnru10>
Hello.
On 29-01-2013 14:17, srinidhi kasagar wrote:
> Get the pl310 rtl revision number which is stashed by the l2x0
> driver and apply the required errata ERRATA_727915 accordingly.
> Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> ---
> arch/arm/mach-omap2/sleep44xx.S | 25 +++++++++++++++++++++----
> 1 files changed, 21 insertions(+), 4 deletions(-)
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> index 88ff83a..7440f65 100644
> --- a/arch/arm/mach-omap2/sleep44xx.S
> +++ b/arch/arm/mach-omap2/sleep44xx.S
> @@ -157,11 +157,19 @@ skip_scu_gp_set:
> ldrne r0, [r8, #L2X0_SAVE_OFFSET1] @ memory.
> cmp r0, #3
> bne do_WFI
> -#ifdef CONFIG_PL310_ERRATA_727915
> + /* Check for PL310_ERRATA_727915 */
> + ldr r0, =l2x0_revision
> + cmp r0, #0x4
> + beq dosmc
> + cmp r0, #0x5
> + beq dosmc
> + b nosmc
Why not just:
bne nosmc
> +dosmc:
> mov r0, #0x03
> mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> DO_SMC
> -#endif
> +
> +nosmc:
> bl omap4_get_l2cache_base
> mov r2, r0
> ldr r0, =0xffff
> @@ -171,11 +179,20 @@ wait:
> ldr r1, =0xffff
> ands r0, r0, r1
> bne wait
> -#ifdef CONFIG_PL310_ERRATA_727915
> +
> + /* Check for PL310_ERRATA_727915 */
> + ldr r0, =l2x0_revision
> + cmp r0, #0x4
> + beq dosmc2
> + cmp r0, #0x5
> + beq dosmc2
> + b nosmc2
Same question.
> +dosmc2:
> mov r0, #0x00
> mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX
> DO_SMC
> -#endif
> +
> +nosmc2:
> l2x_sync:
> bl omap4_get_l2cache_base
> mov r2, r0
WBR, Sergei
^ permalink raw reply
* Section mismatch in drivers/mfd/vexpress-sysreg.c
From: Pawel Moll @ 2013-01-29 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129115535.GH21504@S2101-09.ap.freescale.net>
On Tue, 2013-01-29 at 11:55 +0000, Shawn Guo wrote:
> I'm building v3.8-rc5 and seeing the following section mismatch warning
> in drivers/mfd/vexpress-sysreg.c.
>
> WARNING: drivers/mfd/built-in.o(.text+0x3108): Section mismatch in reference from the function vexpress_sysreg_probe() to the function .init.text:vexpress_sysreg_setup()
> The function vexpress_sysreg_probe() references
> the function __init vexpress_sysreg_setup().
> This is often because vexpress_sysreg_probe lacks a __init
> annotation or the annotation of vexpress_sysreg_setup is wrong.
Arnd's got a fix for this already:
https://patchwork.kernel.org/patch/2046991/
Thanks!
Pawel
^ permalink raw reply
* [PATCH] ARM:common: setting saved_state to NULL after kfree
From: Chen Gang @ 2013-01-29 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107B3B1.1030406@asianux.com>
it is my fault, building failed for not declare sa1111_remove before using.
I should notice next time (at least, need building).
if sending patch v2 is welcome, I will do.
if need additional test, I should try (I try under qemu virtual machine).
:-)
gchen.
? 2013?01?29? 19:34, Chen Gang ??:
>> > 2. I don't think you tried to build with your patch in place.
>> >
>> >
> it is my fault, just like what you said, I did not try to build.
> and I should try now.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Section mismatch in drivers/mfd/vexpress-sysreg.c
From: Russell King - ARM Linux @ 2013-01-29 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464711.8090.19.camel@hornet>
On Tue, Jan 29, 2013 at 01:05:11PM +0000, Pawel Moll wrote:
> On Tue, 2013-01-29 at 11:55 +0000, Shawn Guo wrote:
> > I'm building v3.8-rc5 and seeing the following section mismatch warning
> > in drivers/mfd/vexpress-sysreg.c.
> >
> > WARNING: drivers/mfd/built-in.o(.text+0x3108): Section mismatch in reference from the function vexpress_sysreg_probe() to the function .init.text:vexpress_sysreg_setup()
> > The function vexpress_sysreg_probe() references
> > the function __init vexpress_sysreg_setup().
> > This is often because vexpress_sysreg_probe lacks a __init
> > annotation or the annotation of vexpress_sysreg_setup is wrong.
>
> Arnd's got a fix for this already:
>
> https://patchwork.kernel.org/patch/2046991/
Adding arm-soc people...
Which wasn't in yesterday's arm-soc though, as highlighted by last night's
autobuild (the build tree was created at 9:28am yesterday, which'll be
just after my arm-soc pull).
^ permalink raw reply
* [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
From: Arnd Bergmann @ 2013-01-29 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359445794.31148.34.camel@smile>
On Tuesday 29 January 2013, Andy Shevchenko wrote:
> > +static int pl022_dma_autoprobe(struct pl022 *pl022)
> > +{
> > + struct device *dev = &pl022->adev->dev;
> > +
> > + /* automatically configure DMA channels from platform, normally using DT */
> > + pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
> > + if (!pl022->dma_rx_channel)
> > + goto err_no_rxchan;
> > +
> > + pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
> > + if (!pl022->dma_tx_channel)
> > + goto err_no_txchan;
> > +
> > + pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
>
> Where this memory will be freed?
> In dependence of the answer could you consider to use
> devm_kmalloc or __get_free_page?
There is another function like this called pl022_dma_probe()
that has the same allocation, and it gets freed in the same place.
It's probably worth changing this into something different, but
I felt that it didn't belong into this patch. I was also not
sure if the best option would be dmam_alloc_coherent, dev_kzalloc,
or __get_free_page.
Arnd
^ permalink raw reply
* [PATCH 5/5] ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT
From: Arnd Bergmann @ 2013-01-29 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpokrvYDaMgB-5HV+bJh01YNU4H5UrSUnzxa_NpvE1qQqiA@mail.gmail.com>
On Tuesday 29 January 2013, Viresh Kumar wrote:
> You forgot spear-devel for this series.
Ok, thanks for adding it.
> > + dma-channels = <8>;
> > + #dma-cells = <3>;
Yep, my mistake again. It was correct in v1 of the patch and then
I changed it so it had to be 4.
Arnd
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Andrew Murray @ 2013-01-29 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-20-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, Jan 28, 2013 at 06:56:28PM +0000, Thomas Petazzoni wrote:
> This driver implements the support for the PCIe interfaces on the
> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
> cover earlier families of Marvell SoCs, such as Dove, Orion and
> Kirkwood.
>
> The driver implements the hw_pci operations needed by the core ARM PCI
> code to setup PCI devices and get their corresponding IRQs, and the
> pci_ops operations that are used by the PCI core to read/write the
> configuration space of PCI devices.
>
> Since the PCIe interfaces of Marvell SoCs are completely separate and
> not linked together in a bus, this driver sets up an emulated PCI host
> bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
> interface.
>
> In addition, this driver enumerates the different PCIe slots, and for
> those having a device plugged in, it sets up the necessary address
> decoding windows, using the new armada_370_xp_alloc_pcie_window()
> function from mach-mvebu/addr-map.c.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[snip]
> +static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> +{
[snip]
> +
> + /*
> + * Build an laddr array that describes the PCI device in a DT
> + * way
> + */
> + laddr[0] = cpu_to_be32(port->devfn << 8);
> + laddr[1] = laddr[2] = 0;
> + intspec = cpu_to_be32(pin);
> +
> + ret = of_irq_map_raw(port->dn, &intspec, 1, laddr, &oirq);
> + if (ret) {
> + dev_err(&pcie->pdev->dev,
> + "%s: of_irq_map_raw() failed, %d\n",
> + __func__, ret);
> + return ret;
> + }
Are you able to replace the above code with a call to of_irq_map_pci? I'm not
sure which approach is better. The of_irq_map_pci function doesn't require the
pin argument and instead uses the DT and/or performs its own pin swizzling. I
guess this means that if there are PCIe devices in the DT tree that does any
thing strange with pins then it would be reflected in the IRQ you get. I've
found that you will also need to provide an implementation of
pcibios_get_phb_of_node for this to work correctly (see my RFC bios32 patch).
> +
> + return irq_create_of_mapping(oirq.controller, oirq.specifier,
> + oirq.size);
> +}
> +static int mvebu_pcie_enable(struct mvebu_pcie *pcie)
> +{
> + struct hw_pci hw;
[snip]
> + pci_common_init(&hw);
> +
> + return mvebu_pcie_window_config(pcie);
> +}
> +
> +static int __init mvebu_pcie_probe(struct platform_device *pdev)
> +{
[snip]
> +
> + mvebu_pcie_enable(pcie);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mvebu_pcie_of_match_table[] = {
> + { .compatible = "marvell,armada-370-xp-pcie", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mvebu_pcie_of_match_table);
> +
> +static struct platform_driver mvebu_pcie_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = "mvebu-pcie",
> + .of_match_table =
> + of_match_ptr(mvebu_pcie_of_match_table),
> + },
> +};
> +
> +static int mvebu_pcie_init(void)
> +{
> + return platform_driver_probe(&mvebu_pcie_driver,
> + mvebu_pcie_probe);
> +}
If you have multiple 'mvebu-pcie' in your DT then you will end up
with multiple calls to
mvebu_pcie_probe/mvebu_pcie_enable/pci_common_init.
However pci_common_init/pcibios_init_hw assumes it will only ever be called
once, and will thus result in trying to create multiple busses with the same
bus number. (The first root bus it creates is always zero provided you haven't
implemented hw->scan).
I noticed this in Thierry's patch set and posted an RFC patch which overcomes
this issue (patchwork.kernel.org/patch/2001171) and others. Perhaps you would
want to include this in your patchset?
Andrew Murray
^ permalink raw reply
* [PATCH] ARM:common: deleting waste code which never execute
From: Chen Gang @ 2013-01-29 13:23 UTC (permalink / raw)
To: linux-arm-kernel
delete the waste code which never execute
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
arch/arm/common/scoop.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
index a5c3dc3..6ef146e 100644
--- a/arch/arm/common/scoop.c
+++ b/arch/arm/common/scoop.c
@@ -232,8 +232,6 @@ static int scoop_probe(struct platform_device *pdev)
return 0;
- if (devptr->gpio.base != -1)
- temp = gpiochip_remove(&devptr->gpio);
err_gpio:
platform_set_drvdata(pdev, NULL);
err_ioremap:
--
1.7.10.4
^ permalink raw reply related
* [PATCH] ARM:common: deleting waste code which never execute
From: Chen Gang @ 2013-01-29 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107CD3B.4080600@asianux.com>
sorry, need send patch v2 (or report warning for temp when building)
? 2013?01?29? 21:23, Chen Gang ??:
>
> delete the waste code which never execute
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> arch/arm/common/scoop.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
> index a5c3dc3..6ef146e 100644
> --- a/arch/arm/common/scoop.c
> +++ b/arch/arm/common/scoop.c
> @@ -232,8 +232,6 @@ static int scoop_probe(struct platform_device *pdev)
>
> return 0;
>
> - if (devptr->gpio.base != -1)
> - temp = gpiochip_remove(&devptr->gpio);
> err_gpio:
> platform_set_drvdata(pdev, NULL);
> err_ioremap:
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Andrew Murray @ 2013-01-29 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122192901.GE30647@obsidianresearch.com>
On Tue, Jan 22, 2013 at 07:29:01PM +0000, Jason Gunthorpe wrote:
> On Thu, Jan 17, 2013 at 04:22:18PM +0000, Andrew Murray wrote:
>
> > > In either of those cases, does it make sense to use the MSI support
> > > outside the scope of the PCI infrastructure? That is, would devices
> > > other than PCI devices be able to generate an MSI?
> >
> > I've come around to your way of thinking. Your approach sounds good for
> > registration of MSI ops - let the RC host driver do it (it probably has its
> > own), or use a helper for following a phandle to get ops that are not part
> > of the driver. MSIs won't be used outside of PCI devices.
>
> Here is a bit of additional info on some MSI stuff..
>
> This can be pretty complex. For instance on hyper transport systems
> the PCI to HT bridge has an MSI controller that maps between PCI and
> HT MSI formats, that mapping is configurable, so technically each
> brige could be considered a MSI controller. Typically the mapping
> controllers are all setup the same so there is not much problem with
> this. However *native* HT devices can (which are super rare) can use a
> different MSI format than PCI devices. From a linux perspective HT is
> just a variant of PCI.
>
> On x86 the MSI is delivered to the CPU APIC complex which converts it
> into a vectored interrupt - part of the value of MSI is that the MSI
> data can vector the interrupt to a specific CPU, or group of CPUs or
> whatever.
>
> Presumably SMP ARMs will evolve similar MSI based interrupt vectoring
> capabilities, and presumably on-chip, non-PCI peripherals will evolve
> options to use MSI as well (ie multi-queue ethernet). So it might be
> worth giving some thought to how things could migrate in that
> direction someday.
>
> I have a bit hacky MSI driver for Kirkwood, this work you have to
> generalize the interface could let me actually upstream it :) The MSI
> is built using the Host2CPU doorbell registers, so it is entirely
> unrelated to the PCI-E RC driver.
>
> However, my use of the MSI driver on kirkwood is to assign MSIs to a
> PCI-E device via non-standard registers, more like an on chip
> peripheral. This is because the Host2CPU doorbell doesn't fit 100%
> perfectly with the standard PCI MSI stuff, and the hardware has funny
> needs.. So an 'allocate a MSI interrupt' API would be snazzy too :)
Thanks for this. I believe Thierry may be working on improving the MSI
API - so perhaps we can see where that takes us.
Andrew Murray
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-29 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpo=rD9=dEaPkKYcj55K4_ebdnU7qjv2TZBUwqHAB+Kk+aw@mail.gmail.com>
On Tuesday 29 January 2013, Viresh Kumar wrote:
> You can still keep fargs as is and just fill them as:
>
> fargs.cfg_lo = 0;
>
> if (DMA_TO_DEV)
> // dest is periph
> fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
> else if (DEV_TO_DMA)
> // src is periph
> fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;
>
> The field size is 4 bits.
Ah, good. So I guess the "dma-requests" property should actually
be "16" then.
Does this mean that an implicit zero request line means memory?
Could we have device-to-device DMAs with this controller, and if
we can, should we have both 'src' and 'dst' fields? Are the
two number ranges sharing the same address space, i.e. is
request '7' as the destination guaranteed to be the same device
as request '7' in the source?
If we need two lines, we could interleave them with the bus
master numbers:
dmas = <&dwdma0 // controller
7 // source request 7
1 // source master 1
0 // dest request 0
0>, // dest master 1
<&dwdma0
0 // source request 0
0 // source master 0
8 // dest request 8
1>; // dest master 1
In theory, we could use bit-stuffing to put them all into
a single 32 bit word I guess, but generally people don't
seem to like that for new bindings.
> > Thanks a lot for the input. When I fix the above, are actually able
> > to test the changes, or have you lost access to the hardware when
> > leaving ST?
>
> I don't have any sort of access for testing these :(
> But, Vipul might try these at his end.
Ok, I see.
Arnd
^ permalink raw reply
* [PATCH v2] ARM:common: deleting waste code which never execute
From: Chen Gang @ 2013-01-29 13:32 UTC (permalink / raw)
To: linux-arm-kernel
deleting waste code which never execute
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
arch/arm/common/scoop.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
index a5c3dc3..a20fa80 100644
--- a/arch/arm/common/scoop.c
+++ b/arch/arm/common/scoop.c
@@ -182,7 +182,6 @@ static int scoop_probe(struct platform_device *pdev)
struct scoop_config *inf;
struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
int ret;
- int temp;
if (!mem)
return -EINVAL;
@@ -232,8 +231,6 @@ static int scoop_probe(struct platform_device *pdev)
return 0;
- if (devptr->gpio.base != -1)
- temp = gpiochip_remove(&devptr->gpio);
err_gpio:
platform_set_drvdata(pdev, NULL);
err_ioremap:
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-29 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129111850.GR23505@n2100.arm.linux.org.uk>
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
> > On Tuesday 29 January 2013, Andy Shevchenko wrote:
> > > On Mon, 2013-01-28 at 21:58 +0000, Arnd Bergmann wrote:
> > > > - if ((last_dw == dw) && (last_bus_id == param))
> > > > + /* both the driver and the device must match */
> > > > + if (chan->device->dev->driver != &dw_driver.driver)
> > >
> > > Could we somehow pass the &.driver to the generic filter function (via
> > > *_dma_controller_register() ? ) and do this to each DMA driver?
>
> How, and what driver gets passed?
of_dma_controller_register (see linux-next) already gets a device_node
of a device that is owned by the driver calling this function. This
driver could in theory pass its 'struct device_driver' as another
argument, although I would expect it to pass its own device specific
object (e.g. struct dw_dma or struct dma_pl330_dmac) as the 'data'
pointer, and from there it can easily check if the device matches.
> > My hope is still that we can avoid using filter functions entirely
> > when we use xlate() logic, and instead just go through the channels
> > of the dma engine we know we are looking at.
>
> Has anyone yet determined whether any of these new DMA engine slave APIs
> are usable for implementations which have a separate MUX between the
> DMA engine and the DMA peripheral?
Can you give an example for this? We were careful to make sure it
works with platforms that connect a slave to multiple dma engines,
out of which any could be used for a given transfer. In the device
tree binding, you specify all possible controllers and give the
alternatives the same name, for example:
serial at 10000000 {
compatible = "arm,pl011", "arm,primecell";
dmas = <dwdma0 7 0>, <dwdma0 8 1>, <&pl330 17>, <&pl330 15>;
dma-names = "rx", "tx", "rx", "tx;
...
};
Here, you hve a UART that can use DMA for both receive and transmit, and
can use either the dw_dma or the pl330 controller for each channel.
The common dmaengine code will try to pick the first available channel
on either one. We can probably try to be smarter about making the decision
which one to use.
Is this what you are referring to?
Arnd
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: kishon @ 2013-01-29 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359458548-25071-1-git-send-email-s.hauer@pengutronix.de>
Hi,
On Tuesday 29 January 2013 04:52 PM, Sascha Hauer wrote:
> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>
> This adds two little devicetree helper functions for determining the
> dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> the devicetree.
>
> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> ---
>
> The properties and their values have been taken from the fsl-mph-dr driver.
> This binding is also documented (though currently not used) for the tegra
> ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> This is a first attempt to parse these bindings at a common place so that
> others can make use of it.
>
> Basically I want to know whether this binding is recommended for new drivers
> since normally the devicetree uses '-' instead of '_', and maybe there are
> other problems with it.
>
> I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> driver also really handles a chipidea core.
>
> Should we agree on this I would convert the fsl-mph-dr driver to use these
> helpers.
>
> Sascha
>
> drivers/usb/core/Makefile | 1 +
> drivers/usb/core/of.c | 76 +++++++++++++++++++++++++++++++++++++++++++++
This file should ideally go into drivers/usb/phy/.
> include/linux/usb/of.h | 22 +++++++++++++
> include/linux/usb/phy.h | 9 ++++++
> 4 files changed, 108 insertions(+)
> create mode 100644 drivers/usb/core/of.c
> create mode 100644 include/linux/usb/of.h
>
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 26059b9..5378add 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -10,5 +10,6 @@ usbcore-y += devio.o notify.o generic.o quirks.o devices.o
>
> usbcore-$(CONFIG_PCI) += hcd-pci.o
> usbcore-$(CONFIG_ACPI) += usb-acpi.o
> +usbcore-$(CONFIG_OF) += of.o
No Kconfig? Shouldn't this file be compiled only when some one is going
to use the PHY?
>
> obj-$(CONFIG_USB) += usbcore.o
> diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
> new file mode 100644
> index 0000000..d000d9f
> --- /dev/null
> +++ b/drivers/usb/core/of.c
> @@ -0,0 +1,76 @@
> +/*
> + * OF helpers for usb devices.
> + *
> + * This file is released under the GPLv2
> + *
> + * Initially copied out of drivers/of/of_net.c
> + */
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/usb/of.h>
> +#include <linux/usb/phy.h>
> +#include <linux/export.h>
> +
> +static const char *usbphy_modes[] = {
> + [USBPHY_INTERFACE_MODE_NA] = "",
> + [USBPHY_INTERFACE_MODE_UTMI] = "utmi",
> + [USBPHY_INTERFACE_MODE_UTMIW] = "utmi_wide",
> + [USBPHY_INTERFACE_MODE_ULPI] = "ulpi",
> + [USBPHY_INTERFACE_MODE_SERIAL] = "serial",
> + [USBPHY_INTERFACE_MODE_HSIC] = "hsic",
> +};
> +
> +/**
> + * of_get_usbphy_mode - Get phy mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'phy_type',
> + * and returns the correspondig enum usb_phy_interface
> + */
> +enum usb_phy_interface of_usb_get_phy_mode(struct device_node *np)
> +{
> + const char *phy_type;
> + int err, i;
> +
> + err = of_property_read_string(np, "phy_type", &phy_type);
> + if (err < 0)
> + return USBPHY_INTERFACE_MODE_NA;
Why don't we use a u32 property type for the *phy-type*? IMHO we should
use string property only when the property should be absolutely
unambiguous (e.g., compatible property should be string).
> +
> + for (i = 0; i < ARRAY_SIZE(usbphy_modes); i++)
> + if (!strcasecmp(phy_type, usbphy_modes[i]))
> + return i;
> +
> + return USBPHY_INTERFACE_MODE_NA;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_phy_mode);
> +
> +static const char *usb_dr_modes[] = {
> + [USB_DR_MODE_UNKNOWN] = "",
> + [USB_DR_MODE_HOST] = "host",
> + [USB_DR_MODE_PERIPHERAL] = "peripheral",
> + [USB_DR_MODE_OTG] = "otg",
> +};
> +
> +/**
> + * of_usb_get_dr_mode - Get dual role mode for given device_node
> + * @np: Pointer to the given device_node
> + *
> + * The function gets phy interface string from property 'dr_mode',
> + * and returns the correspondig enum usb_phy_dr_mode
> + */
> +enum usb_phy_dr_mode of_usb_get_dr_mode(struct device_node *np)
> +{
> + const char *dr_mode;
> + int err, i;
> +
> + err = of_property_read_string(np, "dr_mode", &dr_mode);
> + if (err < 0)
> + return USB_DR_MODE_UNKNOWN;
> +
> + for (i = 0; i < ARRAY_SIZE(usb_dr_modes); i++)
> + if (!strcasecmp(dr_mode, usb_dr_modes[i]))
> + return i;
Same comment applies here too.
Thanks
Kishon
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-29 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129132204.GA23886@arm.com>
Dear Andrew Murray,
On Tue, 29 Jan 2013 13:22:04 +0000, Andrew Murray wrote:
> > +static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> > +{
>
> [snip]
>
> > +
> > + /*
> > + * Build an laddr array that describes the PCI device in a DT
> > + * way
> > + */
> > + laddr[0] = cpu_to_be32(port->devfn << 8);
> > + laddr[1] = laddr[2] = 0;
> > + intspec = cpu_to_be32(pin);
> > +
> > + ret = of_irq_map_raw(port->dn, &intspec, 1, laddr, &oirq);
> > + if (ret) {
> > + dev_err(&pcie->pdev->dev,
> > + "%s: of_irq_map_raw() failed, %d\n",
> > + __func__, ret);
> > + return ret;
> > + }
>
> Are you able to replace the above code with a call to of_irq_map_pci? I'm not
> sure which approach is better. The of_irq_map_pci function doesn't require the
> pin argument and instead uses the DT and/or performs its own pin swizzling. I
> guess this means that if there are PCIe devices in the DT tree that does any
> thing strange with pins then it would be reflected in the IRQ you get. I've
> found that you will also need to provide an implementation of
> pcibios_get_phb_of_node for this to work correctly (see my RFC bios32 patch).
I did try using the of_irq_map_pci() function, but unfortunately, it
didn't work. IIRC, it didn't work because none of the pci_dev in my PCI
tree had any 'struct device_node' associated to them, or at least not
the one that had the right pdev->bus->number and pdev->devfn.
But, I guess that your patch that implements pcibios_get_phb_of_node()
should fix this problem. I'll try this. Thanks!
> > +static int mvebu_pcie_init(void)
> > +{
> > + return platform_driver_probe(&mvebu_pcie_driver,
> > + mvebu_pcie_probe);
> > +}
>
> If you have multiple 'mvebu-pcie' in your DT then you will end up
> with multiple calls to
> mvebu_pcie_probe/mvebu_pcie_enable/pci_common_init.
Right. In practice, there will only ever be a single DT node, since all
PCIe interfaces are sub-nodes of the PCI controller node. But I
understand the theoretical problem.
> However pci_common_init/pcibios_init_hw assumes it will only ever be called
> once, and will thus result in trying to create multiple busses with the same
> bus number. (The first root bus it creates is always zero provided you haven't
> implemented hw->scan).
>
> I noticed this in Thierry's patch set and posted an RFC patch which overcomes
> this issue (patchwork.kernel.org/patch/2001171) and others. Perhaps you would
> want to include this in your patchset?
Sure, I'll give it a test, and report if it works for me.
Thanks a lot!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Andy Shevchenko @ 2013-01-29 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301291331.48427.arnd@arndb.de>
On Tue, 2013-01-29 at 13:31 +0000, Arnd Bergmann wrote:
> On Tuesday 29 January 2013, Viresh Kumar wrote:
> > You can still keep fargs as is and just fill them as:
> >
> > fargs.cfg_lo = 0;
> >
> > if (DMA_TO_DEV)
> > // dest is periph
> > fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
> > else if (DEV_TO_DMA)
> > // src is periph
> > fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;
> >
> > The field size is 4 bits.
>
> Ah, good. So I guess the "dma-requests" property should actually
> be "16" then.
>
> Does this mean that an implicit zero request line means memory?
No, it doesn't.
When dma is doing mem2mem transfers the request line field is ignored by
the hw.
> Could we have device-to-device DMAs with this controller, and if
> we can, should we have both 'src' and 'dst' fields?
As far as I know there is no driver under dmaengine that supports
per2per transfers.
> Are the
> two number ranges sharing the same address space, i.e. is
> request '7' as the destination guaranteed to be the same device
> as request '7' in the source?
Request line should be unique. It means a real wire from slave hw to the
dmac.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Wolfram Sang @ 2013-01-29 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107D253.5030400@ti.com>
> >+ err = of_property_read_string(np, "phy_type", &phy_type);
> >+ if (err < 0)
> >+ return USBPHY_INTERFACE_MODE_NA;
>
> Why don't we use a u32 property type for the *phy-type*? IMHO we
> should use string property only when the property should be
> absolutely unambiguous (e.g., compatible property should be string).
If we would use u32-numbers in the compatible entry, this would also be
unambiguous, no? 0xd00dfeed would be the at24-driver. Pretty specific.
I don't mind having readable devicetrees. And we have it for ethernet
phys already with strings, so it would be consistent.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/0b5575ea/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-01-29 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-2-git-send-email-jhovold@gmail.com>
On 13:28 Mon 10 Dec , Johan Hovold wrote:
> Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
> 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
> modes for older SOCs which use IBGR:555 (msb is intensity) rather
> than BGR:565.
>
> Use SOC-type to determine the pixel layout.
>
> Tested on custom at91sam9263-board.
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Johan Hovold <jhovold@gmail.com>
> ---
> drivers/video/atmel_lcdfb.c | 22 +++++++++++++++-------
> include/video/atmel_lcdc.h | 1 +
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 1505539..1f68fa6 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -422,17 +422,22 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> = var->bits_per_pixel;
> break;
> case 16:
> + /* Older SOCs use IBGR:555 rather than BGR:565. */
> + if (sinfo->have_intensity_bit)
> + var->green.length = 5;
> + else
> + var->green.length = 6;
> +
> if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
> - /* RGB:565 mode */
> - var->red.offset = 11;
> + /* RGB:5X5 mode */
> + var->red.offset = var->green.length + 5;
> var->blue.offset = 0;
> } else {
> - /* BGR:565 mode */
> + /* BGR:5X5 mode */
> var->red.offset = 0;
> - var->blue.offset = 11;
> + var->blue.offset = var->green.length + 5;
> }
> var->green.offset = 5;
> - var->green.length = 6;
> var->red.length = var->blue.length = 5;
> break;
> case 32:
> @@ -679,8 +684,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
>
> case FB_VISUAL_PSEUDOCOLOR:
> if (regno < 256) {
> - if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
> - || cpu_is_at91sam9rl()) {
> + if (sinfo->have_intensity_bit) {
> /* old style I+BGR:555 */
> val = ((red >> 11) & 0x001f);
> val |= ((green >> 6) & 0x03e0);
> @@ -870,6 +874,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> }
> sinfo->info = info;
> sinfo->pdev = pdev;
> + if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
> + cpu_is_at91sam9rl()) {
> + sinfo->have_intensity_bit = true;
> + }
nack
you need to drop the cpu_is as this can only be use now for the core
use platform_device_id to indetify the IP as done on at91-i2c as we can not
detect the IP version
Best Regards,
J.
>
> strcpy(info->fix.id, sinfo->pdev->name);
> info->flags = ATMEL_LCDFB_FBINFO_DEFAULT;
> diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
> index 28447f1..5f0e234 100644
> --- a/include/video/atmel_lcdc.h
> +++ b/include/video/atmel_lcdc.h
> @@ -62,6 +62,7 @@ struct atmel_lcdfb_info {
> void (*atmel_lcdfb_power_control)(int on);
> struct fb_monspecs *default_monspecs;
> u32 pseudo_palette[16];
> + bool have_intensity_bit;
> };
>
> #define ATMEL_LCDC_DMABADDR1 0x00
> --
> 1.8.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox