Re: [PATCH 2/3] PCI: host: pcie-designware: add support for suspend and resume
On Friday, July 10, 2015 at 05:30:46 PM, Pratyush Anand wrote: Hi Kishon, Hi, On Fri, Jul 10, 2015 at 8:19 PM, Kishon Vijay Abraham I kis...@ti.com wrote: [...] Have you tested with a card having IO space memory as well. I don't have any cards with IO space memory. Do you have any suggestion for cards with IO space memory? Sorry, I never used it either :( IIRC, then Tim and Marek (in cc) had reported long back with some issues of IO transaction with SKY2 based card. They may let you know about exact card ID. That was Tim, I didn't ever try with SKY2 , sorry. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Tuesday, May 06, 2014 at 03:33:51 PM, Kishon Vijay Abraham I wrote:
Added support for pcie controller in dra7xx. This driver re-uses
the designware core code that is already present in kernel.
[...]
+#define to_dra7xx_pcie(x)container_of((x), struct dra7xx_pcie, pp)
+
+static inline u32 dra7xx_pcie_readl(void __iomem *base, u32 offset)
Just pass struct dra7xx_pcie * instead of *base here , it will make the code
below shorter.
+{
+ return readl(base + offset);
+}
+
+static inline void dra7xx_pcie_writel(void __iomem *base, u32 offset, u32
value) +{
DTTO.
+ writel(value, base + offset);
+}
+
+static int dra7xx_pcie_link_up(struct pcie_port *pp)
+{
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+ u32 reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_PHY_CS);
+
+ if (reg LINK_UP)
+ return true;
+ return false;
return reg LINK_UP;
+}
+
+static int dra7xx_pcie_establish_link(struct pcie_port *pp)
+{
+ u32 reg;
+ int retries = 1000;
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+
+ if (dw_pcie_link_up(pp)) {
+ dev_err(pp-dev, link is already up\n);
This will spew, since the .link_up (and thus this function) can be called
repeatedly. The subsystem will query if the link is up via this function.
+ return 0;
+ }
+
+ reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+ reg |= LTSSM_EN;
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg);
+
+ while (--retries) {
Use retries--
+ reg = dra7xx_pcie_readl(dra7xx-base,
+ PCIECTRL_DRA7XX_CONF_PHY_CS);
+ if (reg LINK_UP)
+ break;
+ usleep_range(10, 20);
+ }
+
+ if (retries = 0) {
Then check if retries == 0 and retries can be unsigned int.
+ dev_err(pp-dev, link is not up\n);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
[...]
+static int __init dra7xx_pcie_probe(struct platform_device *pdev)
+{
+ u32 reg;
+ int ret;
+ int irq;
+ struct phy *phy;
+ void __iomem *base;
+ struct resource *res;
+ struct dra7xx_pcie *dra7xx;
+ struct device *dev = pdev-dev;
+
+ dra7xx = devm_kzalloc(pdev-dev, sizeof(*dra7xx), GFP_KERNEL);
+ if (!dra7xx)
+ return -ENOMEM;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(dev, missing IRQ resource\n);
+ return -EINVAL;
+ }
+
+ ret = devm_request_irq(pdev-dev, irq, dra7xx_pcie_irq_handler,
+IRQF_SHARED, dra7xx-pcie-main, dra7xx);
+ if (ret) {
+ dev_err(pdev-dev, failed to request irq\n);
+ return ret;
+ }
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, ti_conf);
+ base = devm_ioremap_nocache(dev, res-start, resource_size(res));
+ if (!base)
+ return -ENOMEM;
+
+ phy = devm_phy_get(dev, pcie-phy);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ ret = phy_init(phy);
+ if (ret 0)
+ return ret;
+
+ ret = phy_power_on(phy);
+ if (ret 0)
+ goto err_power_on;
+
+ dra7xx-base = base;
+ dra7xx-phy = phy;
+ dra7xx-dev = dev;
+
+ pm_runtime_enable(pdev-dev);
+ ret = pm_runtime_get_sync(pdev-dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev, pm_runtime_get_sync failed\n);
+ goto err_runtime_get;
+ }
+
+ reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+ reg = ~LTSSM_EN;
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg);
platform_set_drvdata() should be here, before you add the port.
+ ret = add_pcie_port(dra7xx, pdev);
+ if (ret 0)
+ goto err_add_port;
+
+ platform_set_drvdata(pdev, dra7xx);
+ return 0;
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/12] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Thursday, March 27, 2014 at 12:45:01 PM, Jingoo Han wrote:
On Wednesday, March 26, 2014 10:58 PM, Kishon Vijay Abraham I wrote:
In DRA7, the cpu sees 32bit address, but the pcie controller can see only
28bit address. So whenever the cpu issues a read/write request, the 4
most significant bits are used by L3 to determine the target controller.
For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe
controller but the PCIe controller will see only (0x000_ -
0xFFF_FFF). So for programming the outbound translation window the
*base* should be programmed as 0x000_. Whenever we try to write to
say 0x2000_, it will be translated to whatever we have programmed in
the translation window with base as 0x000_.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
(+cc Pratyush Anand, Marek Vasut, Richard Zhu)
Thanks.
Acked-by: Jingoo Han jg1@samsung.com
This patch has no impact on MX6, the mask on MX6 is ~0 . A few comments below
...
[...]
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c index 17ce88f..98b661c 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -464,6 +464,9 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
return -EINVAL;
}
+ if (of_property_read_u64(np, base-mask, pp-base_mask))
+ pp-base_mask = ~(0x0ULL);
You can just use ~0x0ULL without the () I believe.
[...]
diff --git a/drivers/pci/host/pcie-designware.h
b/drivers/pci/host/pcie-designware.h index 3063b35..3fa12a6 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -35,6 +35,7 @@ struct pcie_port {
struct device *dev;
u8 root_bus_nr;
void __iomem*dbi_base;
+ u64 base_mask;
u64 cfg0_base;
void __iomem*va_cfg0_base;
u64 cfg1_base;
This structure contains a lot of slop, check [1] please. We really should be
more careful about the structures. I think a separate patch to clean this up
would be fine though.
[1] http://www.catb.org/esr/structure-packing/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Wednesday, December 11, 2013 at 05:18:45 AM, Sourav Poddar wrote: Hi Marek, On Tuesday 10 December 2013 06:19 PM, Marek Vasut wrote: On Friday, December 06, 2013 at 03:24:41 PM, Sourav Poddar wrote: The patch series aims to add memory mapped support for TI qspi contoller and also add support for the same in serial flash driver(m25p80). My question is, shall we not wait for the new SPI NOR framework to be well fleshed out and only then implement this controller driver on top of it ? I think it will still take lot of time for spi framework to come to alignment and get merged in the mainline. Till then, m25p80 development should go on independently. Once, the spi framework is ready, I can myself port this into the new framework. Sure, but I also think Huang is coming close to the new framework. Have you seen his latest patchset ( Message-ID: 1386318764-15882-1-git-send-email- b32...@freescale.com ) ? I think you two should really start working on the new framework instead of bending drivers all around. I have a feeling this patchset adds quite a lot of ad-hoc hacks into the m25p80 driver, which would become dead code once converted to the SPI NOR framework. I dont think that spi framework till now provides capabilities which can be used to handle memory mapped cases. Not yet, so please bring it up in the discussion there :) I did a quad mode support for m25p80 which easily got cloned into the new spi framework. Same can be done for the memory mapped support too The quad mode didn't need any new hooks in the m25p80, did it ? That's the difference here. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 03/10] spi/qspi: Add support to switc to memory mapped operation.
On Friday, December 06, 2013 at 03:24:44 PM, Sourav Poddar wrote:
These add apis that can be used to switch to memory mapped operatons
by configuring control module and qspi registers.
It also add master-mmap property to show that qspi
supports memory mapped operation.
Please fix the 'switc' in the subject, should be 'switch' :)
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2:
Squash a patch to add mater-mmap here itself.
drivers/spi/spi-ti-qspi.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index a0cee08..48294d1 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -113,6 +113,10 @@ struct ti_qspi {
#define QSPI_CSPOL(n)(1 (1 + n * 8))
#define QSPI_CKPOL(n)(1 (n * 8))
+#define MM_SWITCH(1 0)
+#define MEM_CS (1 8)
+#define MEM_CS_DIS (0 8)
You might want to be consistent here, I'd use MEM_CS_EN and MEM_CS_DIS. But
please see below first as MEM_CS_DIS won't be needed, so MEM_CS can be
preserved
as is and MEM_CS_DIS removed altogether.
+
#define QSPI_FRAME 4096
#define QSPI_AUTOSUSPEND_TIMEOUT 2000
@@ -129,6 +133,30 @@ static inline void ti_qspi_write(struct ti_qspi *qspi,
writel(val, qspi-base + reg);
}
+static void enable_qspi_memory_mapped(struct ti_qspi *qspi)
+{
+ u32 val;
+
+ ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+ if (qspi-ctrl_mod) {
+ val = readl(qspi-ctrl_base);
+ val |= MEM_CS;
+ writel(val, qspi-ctrl_base);
+ }
+}
+
+static void disable_qspi_memory_mapped(struct ti_qspi *qspi)
+{
+ u32 val;
+
+ ti_qspi_write(qspi, ~MM_SWITCH, QSPI_SPI_SWITCH_REG);
+ if (qspi-ctrl_mod) {
+ val = readl(qspi-ctrl_base);
+ val = MEM_CS_DIS;
This will likely break once SWITCH_REG contains more than one bit, you can fix
this by using val = ~MEM_CS; instead, which will also get rid of the
MEM_CS_DIS bit.
+ writel(val, qspi-ctrl_base);
+ }
+}
+
static int ti_qspi_setup(struct spi_device *spi)
{
struct ti_qspi *qspi = spi_master_get_devdata(spi-master);
@@ -459,6 +487,7 @@ static int ti_qspi_probe(struct platform_device *pdev)
master-transfer_one_message = ti_qspi_start_transfer_one;
master-dev.of_node = pdev-dev.of_node;
master-bits_per_word_mask = BIT(32 - 1) | BIT(16 - 1) | BIT(8 - 1);
+ master-mmap = true;
if (!of_property_read_u32(np, num-cs, num_cs))
master-num_chipselect = num_cs;
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 05/10] spi/qspi: Add api for get_buf/put_buf.
On Friday, December 06, 2013 at 03:24:46 PM, Sourav Poddar wrote:
Adapt qspi driver to use (get_buf/put_buf) pointers added
earlier.
These can be called just before the memcpy operations to get hold
of the memory mapped address and to turn on the controller clocks.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
v1-v2:
enable/disable memory mapped only when get_buf/put_buf is
called (basicaaly only when memory mapped read operation is
desired).
drivers/spi/spi-ti-qspi.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index e4a8afc..b83583c 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -248,6 +248,23 @@ static void ti_qspi_configure_from_slave(struct
spi_device *spi) ti_qspi_write(qspi, memval, QSPI_SPI_SETUP0_REG);
}
+static inline int __iomem *ti_qspi_get_mem_buf(struct spi_master *master)
Should this not be a 'void __iomem *' instead of 'int __iomem *' in any case ?
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(master);
+
+ pm_runtime_get_sync(qspi-dev);
+ enable_qspi_memory_mapped(qspi);
+ return qspi-mmap_base;
+}
+
+static void ti_qspi_put_mem_buf(struct spi_master *master)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(master);
+
+ disable_qspi_memory_mapped(qspi);
+ pm_runtime_put(qspi-dev);
+}
+
static void ti_qspi_restore_ctx(struct ti_qspi *qspi)
{
struct ti_qspi_regs *ctx_reg = qspi-ctx_reg;
@@ -517,6 +534,8 @@ static int ti_qspi_probe(struct platform_device *pdev)
master-bits_per_word_mask = BIT(32 - 1) | BIT(16 - 1) | BIT(8 - 1);
master-mmap = true;
master-configure_from_slave = ti_qspi_configure_from_slave;
+ master-get_buf = ti_qspi_get_mem_buf;
+ master-put_buf = ti_qspi_put_mem_buf;
if (!of_property_read_u32(np, num-cs, num_cs))
master-num_chipselect = num_cs;
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Friday, December 06, 2013 at 03:24:41 PM, Sourav Poddar wrote: The patch series aims to add memory mapped support for TI qspi contoller and also add support for the same in serial flash driver(m25p80). My question is, shall we not wait for the new SPI NOR framework to be well fleshed out and only then implement this controller driver on top of it ? I have a feeling this patchset adds quite a lot of ad-hoc hacks into the m25p80 driver, which would become dead code once converted to the SPI NOR framework. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 04/10] spi/qspi: configure set up register for memory map.
On Friday, December 06, 2013 at 03:24:45 PM, Sourav Poddar wrote:
These add api to configure set up registers which will be used
for memory mapped operations.
These was provided as a pointer in the earlier patch and can be
used by the slave devices to configure the master controller as an
when required according to the usecases.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/spi/spi-ti-qspi.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 48294d1..e4a8afc 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -117,6 +117,10 @@ struct ti_qspi {
#define MEM_CS (1 8)
#define MEM_CS_DIS (0 8)
+#define QSPI_SETUP0_RD_NORMAL (0x0 12)
+#define QSPI_SETUP0_RD_DUAL (0x1 12)
+#define QSPI_SETUP0_RD_QUAD (0x3 12)
+
#define QSPI_FRAME 4096
#define QSPI_AUTOSUSPEND_TIMEOUT 2000
@@ -220,6 +224,30 @@ static int ti_qspi_setup(struct spi_device *spi)
return 0;
}
+static void ti_qspi_configure_from_slave(struct spi_device *spi)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(spi-master);
+ struct slave_info info = spi-info;
+ u32 memval, mode;
+
+ mode = spi-mode (SPI_RX_DUAL | SPI_RX_QUAD);
+ memval = (info.read_opcode 0) | (info.program_opcode 16) |
+ ((info.addr_width - 1) 8) | (info.dummy_cycles 10);
+
+ switch (mode) {
+ case SPI_RX_DUAL:
+ memval |= QSPI_SETUP0_RD_DUAL;
+ break;
+ case SPI_RX_QUAD:
+ memval |= QSPI_SETUP0_RD_QUAD;
+ break;
+ default:
You want to catch invalid/unsupported mode here instead, so please add 'case
0:'
for 1-bit transfer and treat default: as an error .
+ memval |= QSPI_SETUP0_RD_NORMAL;
+ break;
+ }
+ ti_qspi_write(qspi, memval, QSPI_SPI_SETUP0_REG);
+}
+
static void ti_qspi_restore_ctx(struct ti_qspi *qspi)
{
struct ti_qspi_regs *ctx_reg = qspi-ctx_reg;
@@ -488,6 +516,7 @@ static int ti_qspi_probe(struct platform_device *pdev)
master-dev.of_node = pdev-dev.of_node;
master-bits_per_word_mask = BIT(32 - 1) | BIT(16 - 1) | BIT(8 - 1);
master-mmap = true;
+ master-configure_from_slave = ti_qspi_configure_from_slave;
if (!of_property_read_u32(np, num-cs, num_cs))
master-num_chipselect = num_cs;
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote: On Tue, Dec 10, 2013 at 01:49:13PM +0100, Marek Vasut wrote: My question is, shall we not wait for the new SPI NOR framework to be well fleshed out and only then implement this controller driver on top of it ? I have a feeling this patchset adds quite a lot of ad-hoc hacks into the m25p80 driver, which would become dead code once converted to the SPI NOR framework. There is some stuff that pushes up into the controller in that while the device is in memory mapped mode as far as I can tell it's not safe to do other accesses so if someone's put more than one device on the SPI bus we need to handle interactions there. OK, so it's either-or . That seems OK, you might want to have two drivers for this ip block, one to handle it as a SPI block and one to handle it as a SPI-NOR block. ... that is of course, if these two modes can't work together. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/10] Add memory mapped support for ti qspi, m25p80 serial flash.
On Tuesday, December 10, 2013 at 07:29:04 PM, Mark Brown wrote: On Tue, Dec 10, 2013 at 07:22:10PM +0100, Marek Vasut wrote: On Tuesday, December 10, 2013 at 05:11:43 PM, Mark Brown wrote: There is some stuff that pushes up into the controller in that while the device is in memory mapped mode as far as I can tell it's not safe to do other accesses so if someone's put more than one device on the SPI bus we need to handle interactions there. OK, so it's either-or . That seems OK, you might want to have two drivers for this ip block, one to handle it as a SPI block and one to handle it as a SPI-NOR block. ... that is of course, if these two modes can't work together. Or the client disables the memory map when it's not actively being used and the stops other transfers starting while the mapping is in place. I'd expect we'll have to cope with shared use at some point, hardware engineers will probably build such systems. Aren't we fixing the problem at the wrong place ? Maybe it's about time to fix the engineers ;-) Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/12] drivers/mmc/host: don't use devm_pinctrl_get_select_default() in probe
Dear Wolfram Sang, Since commit ab78029 (drivers/pinctrl: grab default handles from device core), we can rely on device core for setting the default pins. Compile tested only. Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13) Signed-off-by: Wolfram Sang w...@the-dreams.de Something like that is already in -next: mmc: mxs-mmc: Let device core handle pinctrl Otherwise Tested-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
Dear AnilKumar, Chimata, On Fri, Sep 07, 2012 at 05:39:35, Marek Vasut wrote: Dear Tony Lindgren, * Marek Vasut ma...@denx.de [120905 19:05]: Hi Tony, * Marek Vasut ma...@denx.de [120904 20:13]: Dear Bryan Wu, On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch anilku...@ti.com wrote: Adopt pinctrl support to leds-gpio driver based on leds-gpio device pointer, pinctrl driver configure SoC pins to GPIO mode according to definitions provided in .dts file. Thanks for this, actually Marek Vasut submitted a similar patch before. I'm pretty fine with this patch. Thanks for submitting this actually ... I didn't have time to properly investigate this. But without proper DT setting, it will also give us warning I think. or we can provide some dummy functions as a temp solution as Shawn pointed out before. But this driver is also used on hardware that's not yet coverted to DT, so I'd say dev_warn() if CONFIG_OF is enabled and otherwise simply go on ? Actually, can we not skip whole this pinctrl thing if CONFIG_OF is disabled? Actually (2), what's the relationship between OF and pinctrl? The warning should be pinctrl related as the pinctrl drivers may not be device tree based drivers. Exactly my concern. Also the warning shouldnt be present on systems where pinctrl is disabled. But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) Oh all right then. Bryan, If this patch looks fine, can you queue this for 3.7? Looks good to me. Thanks AnilKumar Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
Dear Tony Lindgren, * Marek Vasut ma...@denx.de [120905 19:05]: Hi Tony, * Marek Vasut ma...@denx.de [120904 20:13]: Dear Bryan Wu, On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch anilku...@ti.com wrote: Adopt pinctrl support to leds-gpio driver based on leds-gpio device pointer, pinctrl driver configure SoC pins to GPIO mode according to definitions provided in .dts file. Thanks for this, actually Marek Vasut submitted a similar patch before. I'm pretty fine with this patch. Thanks for submitting this actually ... I didn't have time to properly investigate this. But without proper DT setting, it will also give us warning I think. or we can provide some dummy functions as a temp solution as Shawn pointed out before. But this driver is also used on hardware that's not yet coverted to DT, so I'd say dev_warn() if CONFIG_OF is enabled and otherwise simply go on ? Actually, can we not skip whole this pinctrl thing if CONFIG_OF is disabled? Actually (2), what's the relationship between OF and pinctrl? The warning should be pinctrl related as the pinctrl drivers may not be device tree based drivers. Exactly my concern. Also the warning shouldnt be present on systems where pinctrl is disabled. But pinctrl_get_select() returns 0 in include/linux/pinctrl/consumer.h if CONFIG_PINCTRL is not selected, so no warning is produced AFAIK ;) Oh all right then. Or do you get some warning if CONFIG_PINCTRL is not selected for your hardware? No, I don't have much hardware like such anymore :-( Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
Dear Bryan Wu,
On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch anilku...@ti.com wrote:
Adopt pinctrl support to leds-gpio driver based on leds-gpio
device pointer, pinctrl driver configure SoC pins to GPIO
mode according to definitions provided in .dts file.
Thanks for this, actually Marek Vasut submitted a similar patch
before. I'm pretty fine with this patch.
Thanks for submitting this actually ... I didn't have time to properly
investigate this.
But without proper DT setting, it will also give us warning I think.
or we can provide some dummy functions as a temp solution as Shawn
pointed out before.
But this driver is also used on hardware that's not yet coverted to DT, so I'd
say dev_warn() if CONFIG_OF is enabled and otherwise simply go on ? Actually,
can we not skip whole this pinctrl thing if CONFIG_OF is disabled? Actually
(2),
what's the relationship between OF and pinctrl?
-Bryan
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Changes from v1:
- Seperated from Add DT for AM33XX devices patch series
- Incorporated Tony's comments on v1
* Changed to warning message instead od error return
drivers/leds/leds-gpio.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index c032b21..ad577f4 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -20,6 +20,7 @@
#include linux/slab.h
#include linux/workqueue.h
#include linux/module.h
+#include linux/pinctrl/consumer.h
struct gpio_led_data {
struct led_classdev cdev;
@@ -236,8 +237,14 @@ static int __devinit gpio_led_probe(struct
platform_device *pdev)
{
struct gpio_led_platform_data *pdata = pdev-dev.platform_data;
struct gpio_leds_priv *priv;
+ struct pinctrl *pinctrl;
int i, ret = 0;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev,
+ pins are not configured from the driver\n);
+
if (pdata pdata-num_leds) {
priv = devm_kzalloc(pdev-dev,
sizeof_gpio_leds_priv(pdata-num_leds),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-leds in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level
Dear Igor Grinberg,
On 06/13/12 12:03, Zumeng Chen wrote:
于 2012年06月13日 15:51, Igor Grinberg 写道:
On 06/13/12 04:44, Zumeng Chen wrote:
From: Zumeng Chenzumeng.c...@windriver.com
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.
This patch has been validated on 3530evm.
Signed-off-by: Zumeng Chenzumeng.c...@windriver.com
Signed-off-by: Syed Mohammed Khasimkha...@ti.com
---
drivers/input/touchscreen/ads7846.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c index f02028e..459ff29 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
}
ts-gpio_pendown = pdata-gpio_pendown;
+#ifdef CONFIG_ARCH_OMAP3
+/* 310 means about 10 microsecond for omap3 */
+gpio_set_debounce(pdata-gpio_pendown, 310);
+#endif
Unless this concerns many boards/archs/platforms,
Yes, this is the case.
I'd suggest you to implement
the get_pendown_state() method in the board file.
it seems they are different way between gpio and
get_pendown_state, and gpio way is used for omap3
to drive ads7846, so I guess we may have to do like this.
No, this is not (and does not have to be) OMAP wide.
The decision for this is made on per-board basis.
+1 agreed
Regards,
Zumeng
If more users will need this, it can be facilitated in the driver.
(and of course not with the ugly ifdefs...)
} else {
dev_err(spi-dev, no get_pendown_state nor
gpio_pendown?\n);
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] arm: Use the plat_nand default partition parser
Dear H Hartley Sweeten,
Use the default partition parser, cmdlinepart, provided by the plat_nand
driver.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Ryan Mallon rmal...@gmail.com
Cc: Imre Kaloz ka...@openwrt.org
Cc: Krzysztof Halasa k...@pm.waw.pl
Cc: Tony Lindgren t...@atomide.com
Cc: Alexander Clouter a...@digriz.org.uk
Cc: Nicolas Pitre n...@fluxnic.net
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Marek Vasut marek.va...@gmail.com
Acked-by: Marek Vasut marek.va...@gmail.com
---
diff --git a/arch/arm/mach-ep93xx/snappercl15.c
b/arch/arm/mach-ep93xx/snappercl15.c index 0c00852..5df9092 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -82,8 +82,6 @@ static int snappercl15_nand_dev_ready(struct mtd_info
*mtd) return !!(__raw_readw(NAND_CTRL_ADDR(chip)) SNAPPERCL15_NAND_RDY);
}
-static const char *snappercl15_nand_part_probes[] = {cmdlinepart, NULL};
-
static struct mtd_partition snappercl15_nand_parts[] = {
{
.name = Kernel,
@@ -100,7 +98,6 @@ static struct mtd_partition snappercl15_nand_parts[] = {
static struct platform_nand_data snappercl15_nand_data = {
.chip = {
.nr_chips = 1,
- .part_probe_types = snappercl15_nand_part_probes,
.partitions = snappercl15_nand_parts,
.nr_partitions = ARRAY_SIZE(snappercl15_nand_parts),
.options= NAND_NO_AUTOINCR,
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 5ea7909..14d7121 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -105,8 +105,6 @@ static int ts72xx_nand_device_ready(struct mtd_info
*mtd) return !!(__raw_readb(addr) 0x20);
}
-static const char *ts72xx_nand_part_probes[] = { cmdlinepart, NULL };
-
#define TS72XX_BOOTROM_PART_SIZE (SZ_16K)
#define TS72XX_REDBOOT_PART_SIZE (SZ_2M + SZ_1M)
@@ -134,7 +132,6 @@ static struct platform_nand_data ts72xx_nand_data = {
.nr_chips = 1,
.chip_offset= 0,
.chip_delay = 15,
- .part_probe_types = ts72xx_nand_part_probes,
.partitions = ts72xx_nand_parts,
.nr_partitions = ARRAY_SIZE(ts72xx_nand_parts),
},
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c
b/arch/arm/mach-ixp4xx/ixdp425-setup.c index 3d742ae..fccfc73 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -60,8 +60,6 @@ static struct platform_device ixdp425_flash = {
#if defined(CONFIG_MTD_NAND_PLATFORM) || \
defined(CONFIG_MTD_NAND_PLATFORM_MODULE)
-const char *part_probes[] = { cmdlinepart, NULL };
-
static struct mtd_partition ixdp425_partitions[] = {
{
.name = ixp400 NAND FS 0,
@@ -101,7 +99,6 @@ static struct platform_nand_data ixdp425_flash_nand_data
= { .nr_chips = 1,
.chip_delay = 30,
.options= NAND_NO_AUTOINCR,
- .part_probe_types = part_probes,
.partitions = ixdp425_partitions,
.nr_partitions = ARRAY_SIZE(ixdp425_partitions),
},
diff --git a/arch/arm/mach-omap1/board-fsample.c
b/arch/arm/mach-omap1/board-fsample.c index 80bd43c..62a1e11 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -206,14 +206,11 @@ static int nand_dev_ready(struct mtd_info *mtd)
return gpio_get_value(FSAMPLE_NAND_RB_GPIO_PIN);
}
-static const char *part_probes[] = { cmdlinepart, NULL };
-
static struct platform_nand_data nand_data = {
.chip = {
.nr_chips = 1,
.chip_offset= 0,
.options= NAND_SAMSUNG_LP_OPTIONS,
- .part_probe_types = part_probes,
},
.ctrl = {
.cmd_ctrl = nand_cmd_ctl,
diff --git a/arch/arm/mach-omap1/board-h2.c
b/arch/arm/mach-omap1/board-h2.c index c306862..a914a7d 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -200,8 +200,6 @@ static int h2_nand_dev_ready(struct mtd_info *mtd)
return gpio_get_value(H2_NAND_RB_GPIO_PIN);
}
-static const char *h2_part_probes[] = { cmdlinepart, NULL };
-
static struct platform_nand_data h2_nand_platdata = {
.chip = {
.nr_chips = 1,
@@ -209,7 +207,6 @@ static struct platform_nand_data h2_nand_platdata = {
.nr_partitions = ARRAY_SIZE(h2_nand_partitions),
.partitions = h2_nand_partitions,
.options= NAND_SAMSUNG_LP_OPTIONS,
- .part_probe_types = h2_part_probes,
},
.ctrl
Re: [PATCH 1/2] video: omap: Staticise non-exported symbols
/video/omap/lcd_palmz71.c index 2334e56..1ab4847 100644
--- a/drivers/video/omap/lcd_palmz71.c
+++ b/drivers/video/omap/lcd_palmz71.c
@@ -98,7 +98,7 @@ static int palmz71_panel_resume(struct platform_device
*pdev) return 0;
}
-struct platform_driver palmz71_panel_driver = {
+static struct platform_driver palmz71_panel_driver = {
.probe = palmz71_panel_probe,
.remove = palmz71_panel_remove,
.suspend= palmz71_panel_suspend,
I can speak for palmtt and palmz71,
Acked-by: Marek Vasut marek.va...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] video: omap: convert drivers/video/omap/* to use module_platform_driver()
This patch converts the drivers in drivers/video/omap/* to use the
module_platform_driver() macro which makes the code smaller and a bit
simpler.
Cc: Jonathan McDowell nood...@earth.li
Cc: Cory Maccarrone darkstar6...@gmail.com
Cc: Laurent Gonzalez palmte.li...@free.fr
Cc: Marek Vasut marek.va...@gmail.com
Signed-off-by: Axel Lin axel@gmail.com
---
drivers/video/omap/lcd_ams_delta.c | 13 +
drivers/video/omap/lcd_h3.c| 14 +-
drivers/video/omap/lcd_htcherald.c | 14 +-
drivers/video/omap/lcd_inn1510.c | 14 +-
drivers/video/omap/lcd_inn1610.c | 14 +-
drivers/video/omap/lcd_osk.c | 14 +-
drivers/video/omap/lcd_palmte.c| 14 +-
drivers/video/omap/lcd_palmtt.c| 13 +
drivers/video/omap/lcd_palmz71.c | 13 +
9 files changed, 9 insertions(+), 114 deletions(-)
diff --git a/drivers/video/omap/lcd_ams_delta.c
b/drivers/video/omap/lcd_ams_delta.c index eb50a95..0fdd6f6 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -209,15 +209,4 @@ static struct platform_driver ams_delta_panel_driver =
{ },
};
-static int __init ams_delta_panel_drv_init(void)
-{
- return platform_driver_register(ams_delta_panel_driver);
-}
-
-static void __exit ams_delta_panel_drv_cleanup(void)
-{
- platform_driver_unregister(ams_delta_panel_driver);
-}
-
-module_init(ams_delta_panel_drv_init);
-module_exit(ams_delta_panel_drv_cleanup);
+module_platform_driver(ams_delta_panel_driver);
diff --git a/drivers/video/omap/lcd_h3.c b/drivers/video/omap/lcd_h3.c
index baec34e..49bdeca 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -124,16 +124,4 @@ static struct platform_driver h3_panel_driver = {
},
};
-static int __init h3_panel_drv_init(void)
-{
- return platform_driver_register(h3_panel_driver);
-}
-
-static void __exit h3_panel_drv_cleanup(void)
-{
- platform_driver_unregister(h3_panel_driver);
-}
-
-module_init(h3_panel_drv_init);
-module_exit(h3_panel_drv_cleanup);
-
+module_platform_driver(h3_panel_driver);
diff --git a/drivers/video/omap/lcd_htcherald.c
b/drivers/video/omap/lcd_htcherald.c index b1a022f..20f4778 100644
--- a/drivers/video/omap/lcd_htcherald.c
+++ b/drivers/video/omap/lcd_htcherald.c
@@ -115,16 +115,4 @@ static struct platform_driver htcherald_panel_driver =
{ },
};
-static int __init htcherald_panel_drv_init(void)
-{
- return platform_driver_register(htcherald_panel_driver);
-}
-
-static void __exit htcherald_panel_drv_cleanup(void)
-{
- platform_driver_unregister(htcherald_panel_driver);
-}
-
-module_init(htcherald_panel_drv_init);
-module_exit(htcherald_panel_drv_cleanup);
-
+module_platform_driver(htcherald_panel_driver);
diff --git a/drivers/video/omap/lcd_inn1510.c
b/drivers/video/omap/lcd_inn1510.c index d129946..b38b1dd 100644
--- a/drivers/video/omap/lcd_inn1510.c
+++ b/drivers/video/omap/lcd_inn1510.c
@@ -109,16 +109,4 @@ static struct platform_driver
innovator1510_panel_driver = { },
};
-static int __init innovator1510_panel_drv_init(void)
-{
- return platform_driver_register(innovator1510_panel_driver);
-}
-
-static void __exit innovator1510_panel_drv_cleanup(void)
-{
- platform_driver_unregister(innovator1510_panel_driver);
-}
-
-module_init(innovator1510_panel_drv_init);
-module_exit(innovator1510_panel_drv_cleanup);
-
+module_platform_driver(innovator1510_panel_driver);
diff --git a/drivers/video/omap/lcd_inn1610.c
b/drivers/video/omap/lcd_inn1610.c index a95756b..7e8bd8e 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -133,16 +133,4 @@ static struct platform_driver
innovator1610_panel_driver = { },
};
-static int __init innovator1610_panel_drv_init(void)
-{
- return platform_driver_register(innovator1610_panel_driver);
-}
-
-static void __exit innovator1610_panel_drv_cleanup(void)
-{
- platform_driver_unregister(innovator1610_panel_driver);
-}
-
-module_init(innovator1610_panel_drv_init);
-module_exit(innovator1610_panel_drv_cleanup);
-
+module_platform_driver(innovator1610_panel_driver);
diff --git a/drivers/video/omap/lcd_osk.c b/drivers/video/omap/lcd_osk.c
index b985997..5914220 100644
--- a/drivers/video/omap/lcd_osk.c
+++ b/drivers/video/omap/lcd_osk.c
@@ -127,16 +127,4 @@ static struct platform_driver osk_panel_driver = {
},
};
-static int __init osk_panel_drv_init(void)
-{
- return platform_driver_register(osk_panel_driver);
-}
-
-static void __exit osk_panel_drv_cleanup(void)
-{
- platform_driver_unregister(osk_panel_driver);
-}
-
-module_init(osk_panel_drv_init);
-module_exit(osk_panel_drv_cleanup);
-
+module_platform_driver(osk_panel_driver);
diff --git a/drivers/video/omap/lcd_palmte.c
b/drivers/video/omap
Re: [PATCH] mmc: omap_hsmmc: fix compile break
From: Vikram Pandita vikram.pand...@ti.com
omap_hsmmc.c: In function 'omap_hsmmc_protect_card':
omap_hsmmc.c:1273: error: 'pr_info' undeclared (first use in this function)
omap_hsmmc.c:1273: error: (Each undeclared identifier is reported only once
omap_hsmmc.c:1273: error: for each function it appears in.)
omap_hsmmc.c:1273: error: expected ';' before string constant
omap_hsmmc.c:1275: error: expected statement before ')' token
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e8ff123..101cd31 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1270,7 +1270,7 @@ static void omap_hsmmc_protect_card(struct
omap_hsmmc_host *host) }
} else {
if (!host-protect_card) {
- pr_info%s: cover is open,
+ pr_info(%s: cover is open,
card is now inaccessible\n,
mmc_hostname(host-mmc));
host-protect_card = 1;
Hey,
please care to check mailing list next time before you submit patch. This is
already fixed for about five hours now. Actually, the last patch submitted to
the mailing list fixes exactly this problem:
[PATCH] omap_hsmmc: fix missing parenthesis in pr_info
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: report Data Buffer Error in debug mode
From: Vikram Pandita vikram.pand...@ti.com
Data Buffer Error as per spec section 4.15.1.1.2
results when there is Underrun or Overrun condition.
This error is considered non-fatal and never gets reported.
Its a very good indication on things going wrong at system level,
like running memory at much slower speed.
This is a good error to flag allowing system level corrections.
An issue was found with OMAP4460 board where DDR had to be run
at full speed and this logging helped.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
drivers/usb/host/ehci-q.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 4e4066c..2451361 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -373,6 +373,20 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh
*qh) retry_xacterr:
if ((token QTD_STS_ACTIVE) == 0) {
+ /* Report Data Buffer Error: non-fatal but useful */
+ if (token QTD_STS_DBE) {
+
+ ehci_dbg(ehci,
+ detected DataBufferErr %s for urb %p ep%d%s
len
%d, qtd %p [qh
%p]\n, + (urb-ep-desc.bEndpointAddress
USB_DIR_IN) ?
+ OVER-RUN : UNDER-RUN,
+ urb, urb-ep-desc.bEndpointAddress 0x0f,
+ (urb-ep-desc.bEndpointAddress USB_DIR_IN) ?
in : out,
+ urb-transfer_buffer_length,
+ qtd, urb-ep-hcpriv);
+
+ }
+
/* on STALL, error, and short reads this urb must
* complete and all its qtds must be recycled.
*/
Looks basically ok to me.
Reviewed-by: Marek Vasut marek.va...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
pandaboard brctl oops
Hi, recently a friend of mine sent me this backtrace. I put him in CC so please any subsequent questions shall be forwarded to him. He claims this happens on pandaboard. Cheers root@box:~# brctl addbr br0 root@box:~# brctl addif br0 eth0 [ 77.795776] Unable to handle kernel NULL pointer dereference at virtual address [ 77.804321] pgd = ee8d4000 [ 77.807312] [] *pgd=af8e6831, *pte=, *ppte= [ 77.813995] Internal error: Oops: 8007 [#1] SMP [ 77.819122] last sysfs file: /sys/devices/virtual/net/br0/uevent [ 77.825439] Modules linked in: bridge stp llc wl12xx_sdio wl12xx [ 77.831787] CPU: 0Not tainted (2.6.39.2-omap4 #3) [ 77.837188] PC is at 0x0 [ 77.839904] LR is at br_change_mtu+0x64/0x7c [bridge] [ 77.845214] pc : []lr : [bf068260]psr: 2013 [ 77.845214] sp : ef25de58 ip : ef937e08 fp : [ 77.857299] r10: 0001 r9 : ef25c000 r8 : [ 77.862762] r7 : ef937f00 r6 : ef280540 r5 : ef28 r4 : 05d4 [ 77.869628] r3 : r2 : ef280560 r1 : bf0729e9 r0 : ef280994 [ 77.876495] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 77.883972] Control: 10c5387d Table: ae8d404a DAC: 0015 [ 77.890014] Process brctl (pid: 4290, stack limit = 0xef25c2f8) [ 77.896240] Stack: (0xef25de58 to 0xef25e000) [ 77.900817] de40: ef28 ee88a800 [ 77.909393] de60: ef280540 c0390f54 ef28 bf069d98 ef25ded0 ef28 89a2 [ 77.917999] de80: ef25ded0 c0392390 89a2 ef25ded0 c0c09da0 c03929f4 [ 77.926605] dea0: 0002 006c 0001 ef68bd94 [ 77.935180] dec0: ef68bd80 ef68bd80 ef68bd80 00307262 [ 77.943786] dee0: 0002 bed89d78 4004b450 bed89e79 c0bf3bc8 bed89bbc c171c340 [ 77.952362] df00: 89a2 0003 ef25c000 c011f958 c000 c0120058 [ 77.960968] df20: eacec460 ef820620 ef25c000 c0668464 ef82063c c004c248 [ 77.969573] df40: ef25c000 c012ae44 0002 ef820620 ef25c000 [ 77.978149] df60: c17d4a60 c171c340 bed89bbc 89a2 0003 ef25c000 [ 77.986755] df80: c01200ec 0003 bed89e7f bed89e83 0001 0036 [ 77.995361] dfa0: c004c248 c004c080 bed89e7f bed89e83 0003 89a2 bed89bbc bed89bbc [ 78.003936] dfc0: bed89e7f bed89e83 0001 0036 bed89d78 4005b000 [ 78.012542] dfe0: 40220c30 bed89b94 b0c3 40220c3c 8010 0003 b10d 0407 [ 78.021148] [bf068260] (br_change_mtu+0x64/0x7c [bridge]) from [c0390f54] (dev_set_mtu+0x44/0x7c) [ 78.030883] [c0390f54] (dev_set_mtu+0x44/0x7c) from [bf069d98] (br_add_if+0x2fc/0x3cc [bridge]) [ 78.040405] [bf069d98] (br_add_if+0x2fc/0x3cc [bridge]) from [c0392390] (dev_ifsioc+0x294/0x2b0) [ 78.049987] [c0392390] (dev_ifsioc+0x294/0x2b0) from [c03929f4] (dev_ioctl+0x648/0x748) [ 78.058776] [c03929f4] (dev_ioctl+0x648/0x748) from [c011f958] (vfs_ioctl+0x20/0x3c) [ 78.067291] [c011f958] (vfs_ioctl+0x20/0x3c) from [c0120058] (do_vfs_ioctl+0x4e8/0x530) [ 78.076080] [c0120058] (do_vfs_ioctl+0x4e8/0x530) from [c01200ec] (sys_ioctl+0x4c/0x6c) [ 78.084869] [c01200ec] (sys_ioctl+0x4c/0x6c) from [c004c080] (ret_fast_syscall+0x0/0x3c) [ 78.093749] Code: bad PC value [ 78.098571] ---[ end trace 735bf785e3a5afd2 ]--- Segmentation fault -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP4: Pandaboard: Add omap_reserve functionality
On Wednesday 08 December 2010 08:10:47 Raghuveer Murthy wrote: This patch adds omap_reserve functionality to board-omap4panda.c. Helps in the reserving boot time memory in SDRAM, used here for framebuffer allocation. This patch is in similar lines to commit id 71ee7dad9b6991, from Russell king Russell King ... it's a surname, not a title :-D btw. CCing linux-arm-kernel, as that's a proper mailing list. Cheers Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: linux-...@lists.arm.linux.org.uk Signed-off-by: Raghuveer Murthy raghuveer.mur...@ti.com --- arch/arm/mach-omap2/board-omap4panda.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c index da24745..0ccc24f 100644 --- a/arch/arm/mach-omap2/board-omap4panda.c +++ b/arch/arm/mach-omap2/board-omap4panda.c @@ -393,6 +393,7 @@ MACHINE_START(OMAP4_PANDA, OMAP4 Panda board) /* Maintainer: David Anders - Texas Instruments Inc */ .boot_params= 0x8100, .map_io = omap4_panda_map_io, + .reserve= omap_reserve, .init_irq = omap4_panda_init_irq, .init_machine = omap4_panda_init, .timer = omap_timer, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cpufreq for s3c2440 FriendlyArm
Dne Ne 5. září 2010 22:30:00 tarek attia napsal(a): Hi all, Did anyone try the cpufreq on the mini2440 ? and did anyone get it working on the board ? Each time I do the configuration in the kernel I found nothing on the board ,however after the compilation I found the cpufreq.o pll.o but no file concerning that on the board . Any help will be appreciated. I believe you have the wrong mailing list here. LAK CCed. Best Regards, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
Dne Čt 15. července 2010 08:00:28 Hiroshi DOYU napsal(a): From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 07:56:11 +0200 Dne Čt 15. července 2010 07:39:31 Hiroshi DOYU napsal(a): From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 06:48:50 +0200 Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? What I verified is with OMAP3(Cortex A8) based board. cp15 part has to be modified, but it might work without this part itself, I guess. I see ... do I need any special support on the bootloader or userland side ? No, I don't think so. The resuming boot could set up most of states basically. I'll test it on xscale/pxa270 ... if it works, I can test on various pxa3xx too. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? Thanks -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support
Dne Čt 15. července 2010 07:39:31 Hiroshi DOYU napsal(a): From: ext Marek Vasut marek.va...@gmail.com Subject: Re: [RFC][PATCH 1/1] ARM: Add initial hibernation support Date: Thu, 15 Jul 2010 06:48:50 +0200 Dne St 30. června 2010 16:28:01 Hiroshi DOYU napsal(a): From: Hiroshi DOYU hiroshi.d...@nokia.com Hibernation (a.k.a: Suspend-To-Disk) support for ARM Based on the original work from Romit and Raghu at TI. The original patch(*1) was sent to LOML by Teerth Reddy tee...@ti.com *1: https://patchwork.kernel.org/patch/96442/ Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com Hey, can this also run on pre-v7 arms ? Or is there something I missed that'd make that impossible? What I verified is with OMAP3(Cortex A8) based board. cp15 part has to be modified, but it might work without this part itself, I guess. I see ... do I need any special support on the bootloader or userland side ? Sorry for stupid questions :) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/33] Removing dead SX1_OLD_FLASH
Dne Po 5. července 2010 10:33:48 Tony Lindgren napsal(a): * Marek Vasut marek.va...@gmail.com [100630 21:21]: Dne St 30. června 2010 17:59:25 Christoph Egger napsal(a): SX1_OLD_FLASH doesn't exist in Kconfig, therefore removing all references for it from the source code. There were two models of the phone made, you can toggle between old and new version. Maybe better documentation won't hurt. Sounds like this should be done dynamically based on omap_rev, or some cmdline option from the bootloader? Not applying this one. Tony Yea, the russian guy who ported this is gone I guess though. Just maybe I can get my hands on linux-powered SX1 and try looking into this, but I can't promise it'll be any soon. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/33] Removing dead APM
Dne St 30. června 2010 17:59:06 Christoph Egger napsal(a):
APM doesn't exist in Kconfig, therefore removing all references for it
from the source code.
Tony, do you know Andrzej Zaborowski's new email address? Maybe he should be
CCed here
Signed-off-by: Christoph Egger sicce...@cs.fau.de
---
arch/arm/mach-omap1/board-palmte.c | 84
1 files changed, 0 insertions(+), 84
deletions(-)
diff --git a/arch/arm/mach-omap1/board-palmte.c
b/arch/arm/mach-omap1/board-palmte.c index 569b4c9..23bb0c9 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -213,90 +213,6 @@ static struct omap_lcd_config palmte_lcd_config
__initdata = { .ctrl_name = internal,
};
-#ifdef CONFIG_APM
-/*
- * Values measured in 10 minute intervals averaged over 10 samples.
- * May differ slightly from device to device but should be accurate
- * enough to give basic idea of battery life left and trigger
- * potential alerts.
- */
-static const int palmte_battery_sample[] = {
- 2194, 2157, 2138, 2120,
- 2104, 2089, 2075, 2061,
- 2048, 2038, 2026, 2016,
- 2008, 1998, 1989, 1980,
- 1970, 1958, 1945, 1928,
- 1910, 1888, 1860, 1827,
- 1791, 1751, 1709, 1656,
-};
-
-#define INTERVAL 10
-#define BATTERY_HIGH_TRESHOLD66
-#define BATTERY_LOW_TRESHOLD 33
-
-static void palmte_get_power_status(struct apm_power_info *info, int
*battery) -{
- int charging, batt, hi, lo, mid;
-
- charging = !gpio_get_value(PALMTE_DC_GPIO);
- batt = battery[0];
- if (charging)
- batt -= 60;
-
- hi = ARRAY_SIZE(palmte_battery_sample);
- lo = 0;
-
- info-battery_flag = 0;
- info-units = APM_UNITS_MINS;
-
- if (batt palmte_battery_sample[lo]) {
- info-battery_life = 100;
- info-time = INTERVAL * ARRAY_SIZE(palmte_battery_sample);
- } else if (batt = palmte_battery_sample[hi - 1]) {
- info-battery_life = 0;
- info-time = 0;
- } else {
- while (hi lo + 1) {
- mid = (hi + lo) 1;
- if (batt = palmte_battery_sample[mid])
- lo = mid;
- else
- hi = mid;
- }
-
- mid = palmte_battery_sample[lo] - palmte_battery_sample[hi];
- hi = palmte_battery_sample[lo] - batt;
- info-battery_life = 100 - (100 * lo + 100 * hi / mid) /
- ARRAY_SIZE(palmte_battery_sample);
- info-time = INTERVAL * (ARRAY_SIZE(palmte_battery_sample) -
- lo) - INTERVAL * hi / mid;
- }
-
- if (charging) {
- info-ac_line_status = APM_AC_ONLINE;
- info-battery_status = APM_BATTERY_STATUS_CHARGING;
- info-battery_flag |= APM_BATTERY_FLAG_CHARGING;
- } else {
- info-ac_line_status = APM_AC_OFFLINE;
- if (info-battery_life BATTERY_HIGH_TRESHOLD)
- info-battery_status = APM_BATTERY_STATUS_HIGH;
- else if (info-battery_life BATTERY_LOW_TRESHOLD)
- info-battery_status = APM_BATTERY_STATUS_LOW;
- else
- info-battery_status = APM_BATTERY_STATUS_CRITICAL;
- }
-
- if (info-battery_life BATTERY_HIGH_TRESHOLD)
- info-battery_flag |= APM_BATTERY_FLAG_HIGH;
- else if (info-battery_life BATTERY_LOW_TRESHOLD)
- info-battery_flag |= APM_BATTERY_FLAG_LOW;
- else
- info-battery_flag |= APM_BATTERY_FLAG_CRITICAL;
-}
-#else
-#define palmte_get_power_status NULL
-#endif
-
static struct omap_board_config_kernel palmte_config[] __initdata = {
{ OMAP_TAG_LCD, palmte_lcd_config },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/33] Removing dead SX1_OLD_FLASH
Dne St 30. června 2010 17:59:25 Christoph Egger napsal(a):
SX1_OLD_FLASH doesn't exist in Kconfig, therefore removing all
references for it from the source code.
There were two models of the phone made, you can toggle between old and new
version. Maybe better documentation won't hurt.
Signed-off-by: Christoph Egger sicce...@cs.fau.de
---
arch/arm/mach-omap1/board-sx1.c | 26 --
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap1/board-sx1.c
b/arch/arm/mach-omap1/board-sx1.c index 2fb1e5f..1de809d 100644
--- a/arch/arm/mach-omap1/board-sx1.c
+++ b/arch/arm/mach-omap1/board-sx1.c
@@ -295,31 +295,6 @@ static struct physmap_flash_data sx1_flash_data = {
.nr_parts = ARRAY_SIZE(sx1_partitions),
};
-#ifdef CONFIG_SX1_OLD_FLASH
-/* MTD Intel StrataFlash - old flashes */
-static struct resource sx1_old_flash_resource[] = {
- [0] = {
- .start = OMAP_CS0_PHYS,/* Physical */
- .end= OMAP_CS0_PHYS + SZ_16M - 1,,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = OMAP_CS1_PHYS,
- .end= OMAP_CS1_PHYS + SZ_8M - 1,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device sx1_flash_device = {
- .name = physmap-flash,
- .id = 0,
- .dev= {
- .platform_data = sx1_flash_data,
- },
- .num_resources = 2,
- .resource = sx1_old_flash_resource,
-};
-#else
/* MTD Intel 4000 flash - new flashes */
static struct resource sx1_new_flash_resource = {
.start = OMAP_CS0_PHYS,
@@ -336,7 +311,6 @@ static struct platform_device sx1_flash_device = {
.num_resources = 1,
.resource = sx1_new_flash_resource,
};
-#endif
/*--- USB -*/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lcd rotation in omapfb_main.c
On Wednesday 22 of April 2009 17:38:20 twebb wrote: The L-O tree is already about 2.6.30, so you're essentially 3 revisions out and you're just setting yourself up for a bunch of work to port numerous changes into your Kernel. And as Greg KH would probably say, 5 months in Kernel development land is a really long period of time. :) -- Ashwin Thanks for the clarification. Maybe you could help me understand something about the l-o tree. From what I see on the git, the latest tagged l-o version is 2.6.30-rc2, but my understanding is that only tags that include -omapX have had the latest omap patches applied to it. So I'm not sure what the best choice would be for the 'newest kernel I can find'. Maybe another way to ask this is which would offer better, reasonably stable, omap support: tagged tree v2.6.28-omap1 or v2.6.29, or head omap-2.6.28 or omap-2.6.29 or omap-fixes? I'm not an omap person anymore (though I'll miss working on my omap devices). But, according to README[1], the git address is [2] and you should be fine just doing git clone [3] on it. [1] http://www.muru.com/linux/omap/README_OMAP_GIT [2] http://git.kernel.org/git/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary [3] git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3: Low DDR Memory bandwidth
On Wednesday 04 of February 2009 13:47:41 Ganeshan N wrote: Hi All, I am using OMAP3EVM and measuring DDR memory bandwidth. Used lmbench to measure the bandwidth. I am getting low bandwidth around 460 MB/S in TI kernel 2.6.22 and getting bandwidth around 800 MB/S in git kernel 2.6.28-rc8. In kernel 2.6.22, there are two SDRC registers (SDRC_DLLA_CTRL and SDRC_POWER_REG), which are getting modified. I have updated code such that SDRC values for both the the kernel 2.6.22 and 2.6.28 are same. After this updation there is no improvement in the bandwidth. The SDRC is running at 166MHz. I am using same x-loader and u-boot for both the kernel (2.6.22 and 2.6.28). Can you please suggest some pointers/methods, to increase the DDR memroy bandwidth in 2.6.22 TI kernel. Thanks in advance. why don't you use the .28 one then ? .22 is way too deprecated. With Regards Ganeshan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.27-rc8-omap 0/7] resend of pending TWL patches
On Friday 03 of October 2008 19:38:51 Anand Gadiyar wrote: That's nothing new in David's case ;-) (dont consider this an insult) (Hit reply instead of reply-all... Reminder to self. Never send emails when you're sleepy) On Fri, Oct 3, 2008 at 11:06 PM, Anand Gadiyar [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 10:12 PM, David Brownell [EMAIL PROTECTED] wrote: On Friday 03 October 2008, David Brownell wrote: This flushes my queue of TWL (and related) patches that seem ready to merge: Sanity tested on Beagle, FYI. Where I observed a new oddity: the boot hung right after listing the MTD partitions. Which is where the EHCI code would come up ... took that driver out of the build, and the hang went away. Clue, oh clue; where art thou? Well... Any chance this bit of code here helps? This infinite loop shouldn't even have been here. Oh well. CUT_HERE= Remove infinite loop in DPLL 5 programming. Ideally, DPLL5 should be taken care of by the clock framework. --- drivers/usb/host/ehci-omap.c |2 ++ 1 files changed, 2 insertions(+) Index: linux-omap-2.6/drivers/usb/host/ehci-omap.c === --- linux-omap-2.6.orig/drivers/usb/host/ehci-omap.c2008-09-18 14:59:34.0 +0530 +++ linux-omap-2.6/drivers/usb/host/ehci-omap.c 2008-09-18 15:00:09.737475758 +0530 @@ -170,10 +170,12 @@ static int omap_start_ehc(struct platfor (7 OMAP3430ES2_EN_PERIPH2_DPLL_SHIFT), PLL_MOD, OMAP3430ES2_CM_CLKEN2); +#if 0 while (!(cm_read_mod_reg(PLL_MOD, CM_IDLEST2) OMAP3430ES2_ST_PERIPH2_CLK_MASK)) dev_dbg(hcd-self.controller, idlest2 = 0x%x\n, cm_read_mod_reg(PLL_MOD, CM_IDLEST2)); +#endif /* End DPLL5 programming */ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
