Re: [PATCH v5 0/3] dra7xx: Add PM support to PCIe
On Friday, July 31, 2015 9:25 PM, Kishon Vijay Abraham I wrote: This series adds PM support to pci-dra7xx so that PCI clocks can be disabled during suspend and enabled back during resume without affecting PCI functionality. Changes from v4: *) Fixed a bug caused by sending incomplete patch. Changes from v3: *) Fix compilation errors when individual patches are applied Changes from v2: *) Used SET_SYSTEM_SLEEP_PM_OPS and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS for populating PM ops. Changes from v1: *) Moved resetting and setting of MSE bit to pci-dra7xx. The comment to reset and set ISE is not done now since I don't have a card with IO space. Once I get to test that, I'll post a separate patch for handling that. Kishon Vijay Abraham I (3): PCI: host: pci-dra7xx: Disable pm_runtime on get_sync failure PCI: host: pci-dra7xx: add pm support to pci dra7xx PCI: host: pci-dra7xx: Idle the module by disabling MSE bit Hi Kishon, Looks good! :-) Reviewed-by: Jingoo Han jingooh...@gmail.com Best regards, Jingoo Han drivers/pci/host/pci-dra7xx.c | 95 - 1 file changed, 94 insertions(+), 1 deletion(-) -- 1.7.9.5 -- 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 v3] PCI: kill off set_irq_flags usage
On 2015. 7. 28., at AM 5:55, Rob Herring r...@kernel.org wrote:
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.
Signed-off-by: Rob Herring r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Cc: Murali Karicheri m-kariche...@ti.com
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Jingoo Han jingooh...@gmail.com
Acked-by: Jingoo Han jingooh...@gmail.com
Best regards,
Jingoo Han
Cc: Pratyush Anand pratyush.an...@gmail.com
Cc: Simon Horman ho...@verge.net.au
Cc: Michal Simek michal.si...@xilinx.com
Cc: Sören Brinkmann soren.brinkm...@xilinx.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.
Rob
drivers/pci/host/pci-dra7xx.c | 1 -
drivers/pci/host/pci-keystone-dw.c | 2 --
drivers/pci/host/pci-tegra.c | 1 -
drivers/pci/host/pci-xgene-msi.c | 1 -
drivers/pci/host/pcie-designware.c | 1 -
drivers/pci/host/pcie-rcar.c | 1 -
drivers/pci/host/pcie-xilinx.c | 2 --
7 files changed, 9 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 80db09e..1a0d124 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -155,7 +155,6 @@ static int dra7xx_pcie_intx_map(struct irq_domain
*domain, unsigned int irq,
{
irq_set_chip_and_handler(irq, dummy_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pci-keystone-dw.c
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..f1d0749 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -196,7 +196,6 @@ static int ks_dw_pcie_msi_map(struct irq_domain *domain,
unsigned int irq,
irq_set_chip_and_handler(irq, ks_dw_pcie_msi_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, domain-host_data);
-set_irq_flags(irq, IRQF_VALID);
return 0;
}
@@ -277,7 +276,6 @@ static int ks_dw_pcie_init_legacy_irq_map(struct
irq_domain *d,
irq_set_chip_and_handler(irq, ks_dw_pcie_legacy_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, d-host_data);
-set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 10c0571..81df0c1 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1248,7 +1248,6 @@ static int tegra_msi_map(struct irq_domain *domain,
unsigned int irq,
{
irq_set_chip_and_handler(irq, tegra_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-set_irq_flags(irq, IRQF_VALID);
tegra_cpuidle_pcie_irqs_in_use();
diff --git a/drivers/pci/host/pci-xgene-msi.c
b/drivers/pci/host/pci-xgene-msi.c
index 2d31d4d..8e559d1 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -223,7 +223,6 @@ static int xgene_irq_domain_alloc(struct irq_domain
*domain, unsigned int virq,
irq_domain_set_info(domain, virq, msi_irq,
xgene_msi_bottom_irq_chip, domain-host_data,
handle_simple_irq, NULL, NULL);
-set_irq_flags(virq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 69486be..5c6b562 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -350,7 +350,6 @@ static int dw_pcie_msi_map(struct irq_domain *domain,
unsigned int irq,
{
irq_set_chip_and_handler(irq, dw_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
-set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index c086210..7678fe0 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -664,7 +664,6 @@ static int rcar_msi_map(struct irq_domain *domain,
unsigned int irq,
{
irq_set_chip_and_handler(irq, rcar_msi_irq_chip
Re: [PATCH 2/3] PCI: host: pcie-designware: add support for suspend and resume
On Friday, July 03, 2015 8:04 PM, Kishon Vijay Abraham I wrote:
Certain platforms require MSE bit to be cleared to set the master
in standby mode. (In DRA7xx TRM_vE, section 24.9.4.5.2.2.1 PCIe
This patch is a work-around specific for DRA7xx chips?
If so, please move this patch to 'pci-dra7xx.c'.
I don't want to include chip-specific codes, because
'pcie-designware.c' is designed for including common codes.
Best regards,
Jingoo Han
Controller Master Standby Behavior advises to use the clearing
of the local MSE bit to set the master in standby. Without this
some of the clocks do not idle).
Cleared the MSE bit on suspend and enabled it back on resume.
This is required to get suspend/resume working.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
drivers/pci/host/pcie-designware.c | 20
drivers/pci/host/pcie-designware.h |2 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 69486be..cfb2bd6 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -811,6 +811,26 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
dw_pcie_writel_rc(pp, val, PCI_COMMAND);
}
+void dw_pcie_suspend_rc(struct pcie_port *pp)
+{
+ u32 val;
+
+ /* clear MSE */
+ dw_pcie_readl_rc(pp, PCI_COMMAND, val);
+ val = ~PCI_COMMAND_MEMORY;
+ dw_pcie_writel_rc(pp, val, PCI_COMMAND);
+}
+
+void dw_pcie_resume_rc(struct pcie_port *pp)
+{
+ u32 val;
+
+ /* set MSE */
+ dw_pcie_readl_rc(pp, PCI_COMMAND, val);
+ val |= PCI_COMMAND_MEMORY;
+ dw_pcie_writel_rc(pp, val, PCI_COMMAND);
+}
+
MODULE_AUTHOR(Jingoo Han jg1@samsung.com);
MODULE_DESCRIPTION(Designware PCIe host controller driver);
MODULE_LICENSE(GPL v2);
diff --git a/drivers/pci/host/pcie-designware.h
b/drivers/pci/host/pcie-designware.h
index d0bbd27..0df2dfa 100644
--- a/drivers/pci/host/pcie-designware.h
+++ b/drivers/pci/host/pcie-designware.h
@@ -83,5 +83,7 @@ void dw_pcie_msi_init(struct pcie_port *pp);
int dw_pcie_link_up(struct pcie_port *pp);
void dw_pcie_setup_rc(struct pcie_port *pp);
int dw_pcie_host_init(struct pcie_port *pp);
+void dw_pcie_suspend_rc(struct pcie_port *pp);
+void dw_pcie_resume_rc(struct pcie_port *pp);
#endif /* _PCIE_DESIGNWARE_H */
--
1.7.9.5
--
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 09/13] PCI: kill off set_irq_flags usage
On Sunday, July 12, 2015 11:27 PM, Rob Herring wrote:
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:
IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN
For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.
Signed-off-by: Rob Herring r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Cc: Murali Karicheri m-kariche...@ti.com
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Jingoo Han jingooh...@gmail.com
For pcie-designware.c,
Acked-by: Jingoo Han jingooh...@gmail.com
I checked that the irqdomain core code handles clearing and setting
IRQ_NOREQUEST already, as you said. Thank you.
Best regards,
Jingoo Han
Cc: Pratyush Anand pratyush.an...@gmail.com
Cc: Simon Horman ho...@verge.net.au
Cc: Michal Simek michal.si...@xilinx.com
Cc: Sören Brinkmann soren.brinkm...@xilinx.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Cc: linux...@vger.kernel.org
---
v2:
- Add xgene which was added in v4.2
drivers/pci/host/pci-dra7xx.c | 1 -
drivers/pci/host/pci-keystone-dw.c | 2 --
drivers/pci/host/pci-tegra.c | 1 -
drivers/pci/host/pci-xgene-msi.c | 1 -
drivers/pci/host/pcie-designware.c | 1 -
drivers/pci/host/pcie-rcar.c | 1 -
drivers/pci/host/pcie-xilinx.c | 2 --
7 files changed, 9 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 80db09e..1a0d124 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -155,7 +155,6 @@ static int dra7xx_pcie_intx_map(struct irq_domain
*domain, unsigned int irq,
{
irq_set_chip_and_handler(irq, dummy_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pci-keystone-dw.c
b/drivers/pci/host/pci-keystone-dw.c
index f34892e..f1d0749 100644
--- a/drivers/pci/host/pci-keystone-dw.c
+++ b/drivers/pci/host/pci-keystone-dw.c
@@ -196,7 +196,6 @@ static int ks_dw_pcie_msi_map(struct irq_domain *domain,
unsigned int irq,
irq_set_chip_and_handler(irq, ks_dw_pcie_msi_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
@@ -277,7 +276,6 @@ static int ks_dw_pcie_init_legacy_irq_map(struct
irq_domain *d,
irq_set_chip_and_handler(irq, ks_dw_pcie_legacy_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, d-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 10c0571..81df0c1 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -1248,7 +1248,6 @@ static int tegra_msi_map(struct irq_domain *domain,
unsigned int irq,
{
irq_set_chip_and_handler(irq, tegra_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
tegra_cpuidle_pcie_irqs_in_use();
diff --git a/drivers/pci/host/pci-xgene-msi.c
b/drivers/pci/host/pci-xgene-msi.c
index 2d31d4d..8e559d1 100644
--- a/drivers/pci/host/pci-xgene-msi.c
+++ b/drivers/pci/host/pci-xgene-msi.c
@@ -223,7 +223,6 @@ static int xgene_irq_domain_alloc(struct irq_domain
*domain, unsigned int virq,
irq_domain_set_info(domain, virq, msi_irq,
xgene_msi_bottom_irq_chip, domain-host_data,
handle_simple_irq, NULL, NULL);
- set_irq_flags(virq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 69486be..5c6b562 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -350,7 +350,6 @@ static int dw_pcie_msi_map(struct irq_domain *domain,
unsigned int irq,
{
irq_set_chip_and_handler(irq, dw_msi_irq_chip, handle_simple_irq);
irq_set_chip_data(irq, domain-host_data);
- set_irq_flags(irq, IRQF_VALID);
return 0;
}
diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index c086210..7678fe0 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b
Re: [PATCH v2 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
);
+ goto undo_powerdown;
+ }
+
+ dev_info(pdev-dev, configured as %s DRD\n,
+ dwc3_data-drd_device_conf ? device : host);
+
+ /* ST glue logic init */
+ st_dwc3_init(dwc3_data);
+
+ ret = platform_device_add_resources(dwc3_data-dwc3, pdev-resource,
+ pdev-num_resources);
+ if (ret) {
+ dev_err(pdev-dev, couldn't add resources to dwc3 device\n);
+ goto undo_powerdown;
+ }
+
+ ret = platform_device_add(dwc3_data-dwc3);
+ if (ret) {
+ dev_err(pdev-dev, failed to register dwc3 device\n);
+ goto undo_powerdown;
+ }
+
+ platform_set_drvdata(pdev, dwc3_data);
+
+ return 0;
+
+undo_powerdown:
+ reset_control_assert(dwc3_data-rstc_pwrdn);
+undo_platform_dev_alloc:
+ platform_device_put(pdev);
+
+ return ret;
+
+}
+
+static int st_dwc3_remove(struct platform_device *pdev)
+{
+ struct st_dwc3 *dwc3_data = platform_get_drvdata(pdev);
+
+ platform_device_unregister(dwc3_data-dwc3);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int st_dwc3_suspend(struct device *dev)
+{
+ struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
+
+ reset_control_assert(dwc3_data-rstc_pwrdn);
+
+ pinctrl_pm_select_sleep_state(dev);
+
+ return 0;
+}
+
+static int st_dwc3_resume(struct device *dev)
+{
+ struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
+
+ pinctrl_pm_select_default_state(dev);
+
+ reset_control_deassert(dwc3_data-rstc_pwrdn);
+
+ return 0;
+}
+
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops st_dwc3_dev_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(st_dwc3_suspend, st_dwc3_resume)
+};
+
+static struct of_device_id st_dwc3_match[] = {
Please add 'const' as below. This is because all OF functions
handle of_device_id as const.
static const struct of_device_id st_dwc3_match[] = {
+ { .compatible = st,stih407-dwc3 },
+ { /* sentinel */ },
+};
+
+MODULE_DEVICE_TABLE(of, st_dwc3_match);
+
+static struct platform_driver st_dwc3_driver = {
+ .probe = st_dwc3_probe,
+ .remove = st_dwc3_remove,
+ .driver = {
+ .name = usb-st-dwc3,
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(st_dwc3_match),
You already use OF dependency as below. So, of_match_ptr() is
NOT necessary.
+config USB_DWC3_ST
+ tristate STMicroelectronics Platforms
+ depends on ARCH_STI OF
Please remove of_match_ptr() as below.
+ .of_match_table = st_dwc3_match,
Best regards,
Jingoo Han
+ .pm = st_dwc3_dev_pm_ops,
+ },
+};
+
+module_platform_driver(st_dwc3_driver);
+
+MODULE_AUTHOR(Giuseppe Cavallaro peppe.cavall...@st.com);
+MODULE_DESCRIPTION(DesignWare USB3 STi Glue Layer);
+MODULE_LICENSE(GPL v2);
--
1.9.1
--
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 03/18] PCI: designware: Configuration space should be specified in 'reg'
On Wednesday, June 18, 2014 6:15 PM, Kishon Vijay Abraham I wrote:
On Friday 30 May 2014 07:45 PM, Karicheri, Muralidharan wrote:
On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
The configuration address space has so far been specified in *ranges*,
however it should be specified in *reg* making it a platform MEM resource.
Hence used 'platform_get_resource_*' API to get configuration address
space in the designware driver.
Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Mohit Kumar mohit.ku...@st.com
Cc: Jingoo Han jg1@samsung.com
Cc: Marek Vasut ma...@denx.de
Cc: Arnd Bergmann a...@arndb.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/pci/designware-pcie.txt|1 +
drivers/pci/host/pcie-designware.c | 17
+++--
2 files changed, 16 insertions(+), 2 deletions(-)
[...]
+ cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, config);
+ if (cfg_res) {
+ pp-config.cfg0_size = resource_size(cfg_res)/2;
+ pp-config.cfg1_size = resource_size(cfg_res)/2;
+ pp-cfg0_base = cfg_res-start;
+ pp-cfg1_base = cfg_res-start + pp-config.cfg0_size;
+ } else {
+ dev_err(pp-dev, missing *config* reg space\n);
This should return error -EINVAL.
Just read the other thread and Grant Likely suggested the host controller
driver should be backward compatible [1]. So we can't return -EINVAL here.
So I'd assume this patch is fine as is? Arnd? Jingoo?
Yes, you're right. The driver should keep backward compatibility for
legacy DT binding. However, after enough time goes by, these legacy
DT handling can be removed.
Best regards,
Jingoo Han
[1] - https://lkml.org/lkml/2014/6/3/124
Thanks
Kishon
--
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 16/18] ARM: OMAP: Enable PCI for DRA7
On Thursday, May 29, 2014 3:38 PM, Kishon Vijay Abraham I wrote:
Now that we have added PCIe driver for DRA7 SOCs, enable PCI on
DRA7 SOCs.
Cc: Tony Lindgren t...@atomide.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/Kconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index cb31d43..b179e80 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -75,6 +75,8 @@ config SOC_DRA7XX
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
select IRQ_CROSSBAR
+ select MIGHT_HAVE_PCI
+ select ARCH_SUPPORTS_MSI
Hi Kishon,
Please, don't select ARCH_SUPPORTS_MSI, because this kconfig
option was already removed in v3.12 by the commit ebd97be635
('PCI: remove ARCH_SUPPORTS_MSI kconfig option'). So, there is
NO need to select 'ARCH_SUPPORTS_MSI'.
Best regards,
Jingoo Han
config ARCH_OMAP2PLUS
bool
--
1.7.9.5
--
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 08/16] mtd: nand: omap: Fix build warning
On Wednesday, May 21, 2014 8:21 PM, Roger Quadros wrote: Fix the following warning when CONFIG_MTD_NAND_OMAP_BCH is disabled. warning: ‘erased_sector_bitflips’ defined but not used [-Wunused-function] Signed-off-by: Roger Quadros rog...@ti.com (+cc Christian Engelmayer) The same patch was already sent by Christian Engelmayer. [1] Also, it was applied to mtd tree by Brian Norris. [2] Thank you. [1] http://lists.infradead.org/pipermail/linux-mtd/2014-April/053330.html [2] http://git.infradead.org/users/dedekind/l2-mtd.git/commit/9fd6c6c18c1a4a3220473c76fd447c5708b5ecf9 Best regards, Jingoo Han --- drivers/mtd/nand/omap2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index 1ff49b8..1b800bc 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1237,6 +1237,7 @@ static int __maybe_unused omap_calculate_ecc_bch(struct mtd_info *mtd, return 0; } +#ifdef CONFIG_MTD_NAND_OMAP_BCH /** * erased_sector_bitflips - count bit flips * @data:data sector buffer @@ -1276,7 +1277,6 @@ static int erased_sector_bitflips(u_char *data, u_char *oob, return flip_bits; } -#ifdef CONFIG_MTD_NAND_OMAP_BCH /** * omap_elm_correct_data - corrects page data area in case error reported * @mtd: MTD device structure -- 1.8.3.2 -- 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] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
On Friday, May 09, 2014 10:25 AM, Tony Lindgren wrote: If the GPIO for the backlight is on an I2C chip, we currently get nasty warnings like this during the boot: WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c() Modules linked in: CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400 Workqueue: deferwq deferred_probe_work_func [c0014cbc] (unwind_backtrace) from [c001191c] (show_stack+0x10/0x14) [c001191c] (show_stack) from [c0566ae0] (dump_stack+0x80/0x9c) [c0566ae0] (dump_stack) from [c003f61c] (warn_slowpath_common+0x68/0x8c) [c003f61c] (warn_slowpath_common) from [c003f65c] (warn_slowpath_null+0x1c/0x24) [c003f65c] (warn_slowpath_null) from [c02f7e10] (gpiod_set_raw_value+0x40/0x4c) [c02f7e10] (gpiod_set_raw_value) from [c0308fbc] (gpio_backlight_update_status+0x4c/0x74) [c0308fbc] (gpio_backlight_update_status) from [c030914c] (gpio_backlight_probe+0x168/0x254) [c030914c] (gpio_backlight_probe) from [c0378fa8] (platform_drv_probe+0x18/0x48) [c0378fa8] (platform_drv_probe) from [c0377c40] (driver_probe_device+0x10c/0x238) [c0377c40] (driver_probe_device) from [c0376330] (bus_for_each_drv+0x44/0x8c) [c0376330] (bus_for_each_drv) from [c0377afc] (device_attach+0x74/0x8c) [c0377afc] (device_attach) from [c03771c4] (bus_probe_device+0x88/0xb0) [c03771c4] (bus_probe_device) from [c03775c8] (deferred_probe_work_func+0x64/0x94) [c03775c8] (deferred_probe_work_func) from [c00572e8] (process_one_work+0x1b4/0x4bc) [c00572e8] (process_one_work) from [c00579d0] (worker_thread+0x11c/0x398) [c00579d0] (worker_thread) from [c005dfd8] (kthread+0xc8/0xe4) [c005dfd8] (kthread) from [c000e768] (ret_from_fork+0x14/0x2c) Fix this by using gpio_set_value_cansleep() as suggested in drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers are also doing. Signed-off-by: Tony Lindgren t...@atomide.com (+cc Linus Walleij, Alexandre Courbot, Russell King) Hi Lee Jones, Would you apply this patch into backlight git tree? If you have other opinions, please let us know. :-) Thank you. Acked-by: Jingoo Han jg1@samsung.com Best regards, Jingoo Han --- a/drivers/video/backlight/gpio_backlight.c +++ b/drivers/video/backlight/gpio_backlight.c @@ -38,7 +38,8 @@ static int gpio_backlight_update_status(struct backlight_device *bl) bl-props.state (BL_CORE_SUSPENDED | BL_CORE_FBBLANK)) brightness = 0; - gpio_set_value(gbl-gpio, brightness ? gbl-active : !gbl-active); + gpio_set_value_cansleep(gbl-gpio, + brightness ? gbl-active : !gbl-active); 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: [PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Friday, May 09, 2014 8:50 PM, Kishon Vijay Abraham I wrote: On Thursday 08 May 2014 02:48 PM, Arnd Bergmann wrote: On Thursday 08 May 2014 18:05:11 Jingoo Han wrote: On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 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_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html That is the patch Santosh did for platform devices, which is related but not what I meant here. For the PCI inbound window setup, please have a look at https://lkml.org/lkml/2014/3/19/607 For some reason lkml is not showing any contents. Do you have a different link? Hi Kishon, Please refer to the following link. :-) http://www.spinics.net/lists/linux-pci/msg29855.html Best regards, Jingoo Han -- 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 Wednesday, May 07, 2014 6:26 PM, Arnd Bergmann wrote:
On Wednesday 07 May 2014 14:52:47 Kishon Vijay Abraham I wrote:
On Tuesday 06 May 2014 10:05 PM, Jason Gunthorpe wrote:
On Tue, May 06, 2014 at 07:03:51PM +0530, Kishon Vijay Abraham I wrote:
+Example:
+pcie@5100 {
+compatible = ti,dra7xx-pcie;
+reg = 0x51002000 0x14c, 0x5100 0x2000;
+reg-names = ti_conf, rc_dbics;
+interrupts = 0 232 0x4, 0 233 0x4;
+#address-cells = ;
+#size-cells = 2;
+device_type = pci;
+ti,device_type = ;
+ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /*
Configuration Space */
Configuration space should not show up in the ranges, please don't
copy that mistake from other drivers, put it in reg.
But then it needs pcie-designware.c to be modified and it will be breaking
other platforms no?
I think the pcie-designware driver should be changed to allow either way.
Ideally we would deprecate the existing method in a way that for new
front-ends
it doesn't work, but the old front-ends can still deal with it but also work
if you put it into the reg property.
(+cc Pratyush Anand, Thierry Reding)
Hi Arnd,
Thank you for your comment.
Do you mean the case of Tegra PCIe as below?
./arch/arm/boot/dts/tegra20.dts
pcie-controller@80003000 {
...
reg = 0x80003000 0x0800 /* PADS registers */
0x80003800 0x0200 /* AFI registers */
0x9000 0x1000; /* configuration space */
...
ranges = 0x8200 0 0x8000 0x8000 0 0x1000 /*
port 0 registers */
0x8200 0 0x80001000 0x80001000 0 0x1000 /*
port 1 registers */
0x8100 0 0 0x8200 0 0x0001 /*
downstream I/O */
0x8200 0 0xa000 0xa000 0 0x0800 /*
non-prefetchable memory */
0xc200 0 0xa800 0xa800 0 0x1800; /*
prefetchable memory */
...
./drivers/pci/host/pci-tegra.c
/* request configuration space, but remap later, on demand */
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, cs);
...
pcie-cs = devm_request_mem_region(pcie-dev, res-start,
resource_size(res), res-name);
Best regards,
Jingoo Han
--
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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 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_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html Thank you. Best regards, Jingoo Han I also suspect you will have to implement swiotlb support to make generic PCI devices work behind this bridge. Otherwise you end up with random physical addresses passed into DMA registers. -- 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] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
On Friday, May 09, 2014 10:25 AM, Lee Jones wrote: If the GPIO for the backlight is on an I2C chip, we currently get nasty warnings like this during the boot: WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c() Modules linked in: CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400 Workqueue: deferwq deferred_probe_work_func [c0014cbc] (unwind_backtrace) from [c001191c] (show_stack+0x10/0x14) [c001191c] (show_stack) from [c0566ae0] (dump_stack+0x80/0x9c) [c0566ae0] (dump_stack) from [c003f61c] (warn_slowpath_common+0x68/0x8c) [c003f61c] (warn_slowpath_common) from [c003f65c] (warn_slowpath_null+0x1c/0x24) [c003f65c] (warn_slowpath_null) from [c02f7e10] (gpiod_set_raw_value+0x40/0x4c) [c02f7e10] (gpiod_set_raw_value) from [c0308fbc] (gpio_backlight_update_status+0x4c/0x74) [c0308fbc] (gpio_backlight_update_status) from [c030914c] (gpio_backlight_probe+0x168/0x254) [c030914c] (gpio_backlight_probe) from [c0378fa8] (platform_drv_probe+0x18/0x48) [c0378fa8] (platform_drv_probe) from [c0377c40] (driver_probe_device+0x10c/0x238) [c0377c40] (driver_probe_device) from [c0376330] (bus_for_each_drv+0x44/0x8c) [c0376330] (bus_for_each_drv) from [c0377afc] (device_attach+0x74/0x8c) [c0377afc] (device_attach) from [c03771c4] (bus_probe_device+0x88/0xb0) [c03771c4] (bus_probe_device) from [c03775c8] (deferred_probe_work_func+0x64/0x94) [c03775c8] (deferred_probe_work_func) from [c00572e8] (process_one_work+0x1b4/0x4bc) [c00572e8] (process_one_work) from [c00579d0] (worker_thread+0x11c/0x398) [c00579d0] (worker_thread) from [c005dfd8] (kthread+0xc8/0xe4) [c005dfd8] (kthread) from [c000e768] (ret_from_fork+0x14/0x2c) Fix this by using gpio_set_value_cansleep() as suggested in drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers are also doing. OK, I see. However, gpio_backlight drive can be used by a lot of gpio drivers. In some cases, 'can_sleep' is 'false' and gpio_set_value_cansleep() is unnecessary. In my opinion, gpio_set_value_cansleep() or gpio_set_value() can be called selectively by 'can_sleep' value. How about the following? - gpio_set_value(gbl-gpio, brightness ? gbl-active : !gbl-active); + if (gpio_cansleep(gbl-gpio)) + gpio_set_value_cansleep(gbl-gpio, + brightness ? gbl-active : !gbl-active); + else + gpio_set_value(gbl-gpio, brightness ? gbl-active : !gbl-active); Best regards, Jingoo Han Signed-off-by: Tony Lindgren t...@atomide.com --- a/drivers/video/backlight/gpio_backlight.c +++ b/drivers/video/backlight/gpio_backlight.c @@ -38,7 +38,8 @@ static int gpio_backlight_update_status(struct backlight_device *bl) bl-props.state (BL_CORE_SUSPENDED | BL_CORE_FBBLANK)) brightness = 0; - gpio_set_value(gbl-gpio, brightness ? gbl-active : !gbl-active); + gpio_set_value_cansleep(gbl-gpio, + brightness ? gbl-active : !gbl-active); 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: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
On Friday, May 09, 2014 12:09 PM, Tony Lindgren wrote:
On Friday, May 09, 2014 11:25 AM, Jingoo Han wrote:
On Friday, May 09, 2014 10:25 AM, Lee Jones wrote:
If the GPIO for the backlight is on an I2C chip, we currently
get nasty warnings like this during the boot:
WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364
gpiod_set_raw_value+0x40/0x4c()
Modules linked in:
CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e
#400
Workqueue: deferwq deferred_probe_work_func
[c0014cbc] (unwind_backtrace) from [c001191c] (show_stack+0x10/0x14)
[c001191c] (show_stack) from [c0566ae0] (dump_stack+0x80/0x9c)
[c0566ae0] (dump_stack) from [c003f61c]
(warn_slowpath_common+0x68/0x8c)
[c003f61c] (warn_slowpath_common) from [c003f65c]
(warn_slowpath_null+0x1c/0x24)
[c003f65c] (warn_slowpath_null) from [c02f7e10]
(gpiod_set_raw_value+0x40/0x4c)
[c02f7e10] (gpiod_set_raw_value) from [c0308fbc]
(gpio_backlight_update_status+0x4c/0x74)
[c0308fbc] (gpio_backlight_update_status) from [c030914c]
(gpio_backlight_probe+0x168/0x254)
[c030914c] (gpio_backlight_probe) from [c0378fa8]
(platform_drv_probe+0x18/0x48)
[c0378fa8] (platform_drv_probe) from [c0377c40]
(driver_probe_device+0x10c/0x238)
[c0377c40] (driver_probe_device) from [c0376330]
(bus_for_each_drv+0x44/0x8c)
[c0376330] (bus_for_each_drv) from [c0377afc]
(device_attach+0x74/0x8c)
[c0377afc] (device_attach) from [c03771c4]
(bus_probe_device+0x88/0xb0)
[c03771c4] (bus_probe_device) from [c03775c8]
(deferred_probe_work_func+0x64/0x94)
[c03775c8] (deferred_probe_work_func) from [c00572e8]
(process_one_work+0x1b4/0x4bc)
[c00572e8] (process_one_work) from [c00579d0]
(worker_thread+0x11c/0x398)
[c00579d0] (worker_thread) from [c005dfd8] (kthread+0xc8/0xe4)
[c005dfd8] (kthread) from [c000e768] (ret_from_fork+0x14/0x2c)
Fix this by using gpio_set_value_cansleep() as suggested in
drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
are also doing.
OK, I see.
However, gpio_backlight drive can be used by a lot of gpio drivers.
In some cases, 'can_sleep' is 'false' and gpio_set_value_cansleep()
is unnecessary.
In my opinion, gpio_set_value_cansleep() or gpio_set_value() can be
called selectively by 'can_sleep' value.
How about the following?
- gpio_set_value(gbl-gpio, brightness ? gbl-active : !gbl-active);
+ if (gpio_cansleep(gbl-gpio))
+ gpio_set_value_cansleep(gbl-gpio,
+ brightness ? gbl-active :
!gbl-active);
+ else
+ gpio_set_value(gbl-gpio, brightness ? gbl-active :
!gbl-active);
It should be always fine to use gpio_set_value_cansleep(), see your
old thread from few years ago related to another backlight driver:
https://lkml.org/lkml/2012/12/5/343
(+cc Linus Walleij, Alexandre Courbot, Russell King)
OK, I see.
gpio_set_value_cansleep() calls gpiod_set_raw_value_cansleep(),
and gpio_set_value() calls gpiod_set_raw_value() as below.
./drivers/gpio/gpiolib.c
void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value)
{
might_sleep_if(extra_checks);
if (!desc)
return;
_gpiod_set_raw_value(desc, value);
}
EXPORT_SYMBOL_GPL(gpiod_set_raw_value_cansleep);
./drivers/gpio/gpiolib.c
void gpiod_set_raw_value(struct gpio_desc *desc, int value)
{
if (!desc)
return;
/* Should be using gpio_set_value_cansleep() */
WARN_ON(desc-chip-can_sleep);
_gpiod_set_raw_value(desc, value);
}
EXPORT_SYMBOL_GPL(gpiod_set_raw_value);
Then, the difference between gpio_set_value_cansleep() or
gpio_set_value() is whether might_sleep_if(extra_checks) is
called or not.
So, you said that It should be always fine to use
gpio_set_value_cansleep(), right?
Linus Walleij,
Is there any reason to keep these two functions such as
gpiod_set_raw_value_cansleep() and gpiod_set_raw_value()?
Best regards,
Jingoo Han
--
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] fbdev: omap2: Fix format string mismatch in display-sysfs.c
On Monday, April 28, 2014 7:54 PM, Masanari Iida wrote:
Fix two format string mismatch in display-sysfs.c
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/video/fbdev/omap2/dss/display-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c
b/drivers/video/fbdev/omap2/dss/display-
sysfs.c
index 5a2095a..5928bc9 100644
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -184,7 +184,7 @@ static ssize_t display_rotate_show(struct device *dev,
if (!dssdev-driver-get_rotate)
return -ENOENT;
rotate = dssdev-driver-get_rotate(dssdev);
According to 'struct omap_dss_driver', get_rotate() returns 'u8'.
Then, how about changing the type of 'rotate' variable from 'int'
to 'u8' as below?
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -180,7 +180,7 @@ static ssize_t display_rotate_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
- int rotate;
+ u8 rotate;
if (!dssdev-driver-get_rotate)
return -ENOENT;
rotate = dssdev-driver-get_rotate(dssdev);
Best regards,
Jingoo Han
- return snprintf(buf, PAGE_SIZE, %u\n, rotate);
+ return snprintf(buf, PAGE_SIZE, %d\n, rotate);
}
static ssize_t display_rotate_store(struct device *dev,
@@ -215,7 +215,7 @@ static ssize_t display_mirror_show(struct device *dev,
if (!dssdev-driver-get_mirror)
return -ENOENT;
mirror = dssdev-driver-get_mirror(dssdev);
- return snprintf(buf, PAGE_SIZE, %u\n, mirror);
+ return snprintf(buf, PAGE_SIZE, %d\n, mirror);
}
static ssize_t display_mirror_store(struct device *dev,
--
2.0.0.rc1
--
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 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 3:40 PM, Vivek Gautam wrote:
On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han jg1@samsung.com wrote:
On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
[snip]
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
Oh, right. In the case of exynos5440, regulator settings is not
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.
Sorry, in the case of exynos5440, this patch already skips
regulator settings.
In the case of exynos5440, there is no need to set PHY setting
and regulator setting.
Right, in case of exynos5440, we are skipping PHY setting and regulator
setting.
Actually i had missed taking into account 5440, so just curious. Do we
really not need a regulator
settings for Exynos5440 ?
To be more specific, there is no regulator on ssdk5440 board
which is the Exynos5440-based board.
Best regards,
Jingoo Han
How about making regulator setting optional?
Then, regulator setting can be done, only when regulator
is supported.
True, so with Exynos5440 not needing the regulator, we should make the
regulator settings optional.
[.]
Thanks for the suggestion.
I will make the required changes, and post the patchset again.
OK, I see.
Thank you for accepting my suggestion.
Best regards,
Jingoo Han
--
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 3/3] usb: dwc3-exynos: Make provision for vdd regulators
On Wednesday, April 23, 2014 8:06 PM, Vivek Gautam wrote:
On Wednesday, April 23, 2014 7:58 PM, Anton Tikhomirov wrote:
On Wednesday, April 23, 2014 6:52 PM, Vivek Gautam wrote:
On Wednesday, April 23, 2014 6:27 PM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
DWC3 controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
---
Based on 'usb-next' branch of Greg's USB tree.
Also cleanly applies on 'next' branch of Balbi's USB tree.
drivers/usb/dwc3/dwc3-exynos.c | 51
++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-
exynos.c
index 28c8ad7..c9d9102 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -27,6 +27,7 @@
#include linux/usb/usb_phy_gen_xceiv.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/regulator/consumer.h
struct dwc3_exynos {
struct platform_device *usb2_phy;
@@ -34,6 +35,8 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct regulator*vdd33;
+ struct regulator*vdd10;
};
static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
@@ -144,20 +147,46 @@ static int dwc3_exynos_probe(struct
platform_device *pdev)
clk_prepare_enable(exynos-clk);
+ exynos-vdd33 = devm_regulator_get(dev, vdd33);
+ if (IS_ERR(exynos-vdd33)) {
+ ret = PTR_ERR(exynos-vdd33);
+ goto err2;
Is regulator property mandatory for dwc3-exynos? If it is not
and device tree doesn't provide it, dwc3-exynos driver probe
shouldn't
fail here.
These are the VDD regulators (from PMIC ldo supplies), in absence of
which the controller will not be powered up.
So doesn't it make sense to stop the probe when these are not supplied
by device tree ?
Agree. Just curious, is there special reason for this change except making
things right?
Yea, actually after the patch (which got merged in 3.15 rc1)
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
the USB stops working, and that's because the regulators related to
usb are not turned on by default (ldo12 and ldo15 to be specific).
So we need to enable those regulators, which ofcourse the driver
should be doing, if i am not wrong.
Similar is the reason for EHCI, and OHCI exynos patches in this series.
Oh, I see. Thank you for your explanation.
I shall be sending the dt patch for this soon.
OK, I will wait for your patch.
Best regards,
Jingoo Han
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device *pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct platform_device
*pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
1.7.10.4
--
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] usb: ehci-exynos: Make provision for vdd regulators
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
EHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ehci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index d1d8c47..a3ca8cc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -20,6 +20,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -46,6 +47,8 @@ struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
#define to_exynos_ehci(hcd) (struct exynos_ehci_hcd
*)(hcd_to_ehci(hcd)-priv)
@@ -112,6 +115,28 @@ static int exynos_ehci_probe(struct platform_device
*pdev)
exynos_ehci-otg = phy-otg;
}
+ exynos_ehci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ehci-vdd33)) {
+ err = PTR_ERR(exynos_ehci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ehci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ehci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ehci-vdd10)) {
+ err = PTR_ERR(exynos_ehci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ehci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
skip_phy:
exynos_ehci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -178,6 +203,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ehci-clk);
fail_clk:
+ regulator_disable(exynos_ehci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ehci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -197,6 +226,9 @@ static int exynos_ehci_remove(struct platform_device
*pdev)
clk_disable_unprepare(exynos_ehci-clk);
+ regulator_disable(exynos_ehci-vdd10);
+ regulator_disable(exynos_ehci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -221,6 +253,9 @@ static int exynos_ehci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ehci-clk);
+ regulator_disable(exynos_ehci-vdd10);
+ regulator_disable(exynos_ehci-vdd33);
+
return rc;
}
@@ -228,6 +263,18 @@ static int exynos_ehci_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
+ int ret;
+
+ ret = regulator_enable(exynos_ehci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
+ }
+ ret = regulator_enable(exynos_ehci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ehci-clk);
--
1.7.10.4
--
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 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
Oh, right. In the case of exynos5440, regulator settings is not
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.
Best regards,
Jingoo Han
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1:
usb_put_hcd(hcd);
return err;
}
@@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
platform_device *pdev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
usb_put_hcd(hcd);
return 0;
@@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
+ regulator_disable(exynos_ohci-vdd10);
+ regulator_disable(exynos_ohci-vdd33);
+
spin_unlock_irqrestore(ohci-lock, flags);
return 0;
@@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct platform_device *pdev= to_platform_device(dev);
+ int ret;
+
+ ret = regulator_enable(exynos_ohci-vdd33);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD33 supply\n);
+ return ret;
Not sure, but shall we continue resuming and do everything
we can in case of error? At least it will avoid
WARN_ON(clk-enable_count == 0) on next system suspend.
+ }
+ ret = regulator_enable(exynos_ohci-vdd10);
+ if (ret) {
+ dev_err(dev, Failed to enable VDD10 supply\n);
+ return ret;
+ }
clk_prepare_enable(exynos_ohci-clk);
--
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: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
Facilitate getting required 3.3V and 1.0V VDD supply for
OHCI controller on Exynos.
With patches for regulators' nodes merged in 3.15:
c8c253f ARM: dts: Add regulator entries to smdk5420
275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
certain perripherals will now need to ensure that,
they request VDD regulators in their drivers, and enable
them so as to make them working.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Jingoo Han jg1@samsung.com
---
Based on 'usb-next' branch of Greg's usb tree.
drivers/usb/host/ohci-exynos.c | 47
1 file changed, 47 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
exynos.c
index 68588d8..e2e72a8 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
#include linux/usb.h
@@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+ struct regulator *vdd33;
+ struct regulator *vdd10;
};
static void exynos_ohci_phy_enable(struct platform_device *pdev)
@@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
*pdev)
exynos_ohci-otg = phy-otg;
}
+ exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
+ if (IS_ERR(exynos_ohci-vdd33)) {
+ err = PTR_ERR(exynos_ohci-vdd33);
+ goto fail_regulator1;
+ }
+ err = regulator_enable(exynos_ohci-vdd33);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD33 supply\n);
+ goto fail_regulator1;
+ }
+
+ exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
+ if (IS_ERR(exynos_ohci-vdd10)) {
+ err = PTR_ERR(exynos_ohci-vdd10);
+ goto fail_regulator2;
+ }
+ err = regulator_enable(exynos_ohci-vdd10);
+ if (err) {
+ dev_err(pdev-dev, Failed to enable VDD10 supply\n);
+ goto fail_regulator2;
+ }
+
Do we need to skip regulator settings together with PHY configuration
in case of exynos5440?
Oh, right. In the case of exynos5440, regulator settings is not
necessary. Vivek, would you fix it in order skip regulator settings
in exynos5440? It also applies to ehci-exynos.
Sorry, in the case of exynos5440, this patch already skips
regulator settings.
In the case of exynos5440, there is no need to set PHY setting
and regulator setting.
How about making regulator setting optional?
Then, regulator setting can be done, only when regulator
is supported.
exynos_ohci_probe()
exynos_ohci-vdd33 = devm_regulator_get(pdev-dev, vdd33);
if (IS_ERR(exynos_ohci-vdd33)) {
dev_err(pdev-dev, Failed to get VDD33 supply\n);
} else {
err = regulator_enable(exynos_ohci-vdd33);
if (err) {
dev_err(pdev-dev, Failed to enable VDD33 supply\n);
goto fail_regulator1;
}
}
exynos_ohci-vdd10 = devm_regulator_get(pdev-dev, vdd10);
if (IS_ERR(exynos_ohci-vdd10)) {
dev_err(pdev-dev, Failed to get VDD10 supply\n);
} else {
err = regulator_enable(exynos_ohci-vdd10);
if (err) {
dev_err(pdev-dev, Failed to enable VDD10 supply\n);
goto fail_regulator2;
}
}
In this case, suspend/resume can be fixed as below.
exynos_ohci_suspend()
if (exynos_ohci-vdd10)
regulator_disable(exynos_ohci-vdd10);
if (exynos_ohci-vdd33)
regulator_disable(exynos_ohci-vdd33);
exynos_ohci_resume()
if (exynos_ohci-vdd33) {
ret = regulator_enable(exynos_ohci-vdd33);
if (ret) {
dev_err(dev, Failed to enable VDD33 supply\n);
return ret;
}
}
if (exynos_ohci-vdd10) {
ret = regulator_enable(exynos_ohci-vdd10);
if (ret) {
dev_err(dev, Failed to enable VDD10 supply\n);
return ret;
}
}
Best regards,
Jingoo Han
skip_phy:
exynos_ohci-clk = devm_clk_get(pdev-dev, usbhost);
@@ -154,6 +179,10 @@ fail_add_hcd:
fail_io:
clk_disable_unprepare(exynos_ohci-clk);
fail_clk:
+ regulator_disable(exynos_ohci-vdd10);
+fail_regulator2:
+ regulator_disable(exynos_ohci-vdd33);
+fail_regulator1
Re: [RFC PATCH 03/12] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
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)
Acked-by: Jingoo Han jg1@samsung.com
Mohit Kumar, Pratyush Anand,
If you have other opinions, please let us know. :-)
Thank you.
Best regards,
Jingoo Han
---
.../devicetree/bindings/pci/designware-pcie.txt|1 +
drivers/pci/host/pcie-designware.c | 39
++--
drivers/pci/host/pcie-designware.h |1 +
3 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13..c574dd3 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -27,6 +27,7 @@ Optional properties for fsl,imx6q-pcie
- power-on-gpio: gpio pin number of power-enable signal
- wake-up-gpio: gpio pin number of incoming wakeup signal
- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
+- base-mask: address mask for the PCIe controller target port
Example:
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);
+
if (IS_ENABLED(CONFIG_PCI_MSI)) {
pp-irq_domain = irq_domain_add_linear(pp-dev-of_node,
MAX_MSI_IRQS, msi_domain_ops,
@@ -503,12 +506,15 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
static void dw_pcie_prog_viewport_cfg0(struct pcie_port *pp, u32 busdev)
{
+ u64 cfg0_base;
+
+ cfg0_base = pp-cfg0_base pp-base_mask;
/* Program viewport 0 : OUTBOUND : CFG0 */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, pp-cfg0_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp-cfg0_base 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp-cfg0_base + pp-config.cfg0_size - 1,
+ dw_pcie_writel_rc(pp, cfg0_base, PCIE_ATU_LOWER_BASE);
+ dw_pcie_writel_rc(pp, (cfg0_base 32), PCIE_ATU_UPPER_BASE);
+ dw_pcie_writel_rc(pp, cfg0_base + pp-config.cfg0_size - 1,
PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
@@ -518,14 +524,17 @@ static void dw_pcie_prog_viewport_cfg0(struct pcie_port
*pp, u32 busdev)
static void dw_pcie_prog_viewport_cfg1(struct pcie_port *pp, u32 busdev)
{
+ u64 cfg1_base;
+
+ cfg1_base = pp-cfg1_base pp-base_mask;
/* Program viewport 1 : OUTBOUND : CFG1 */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1,
PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_CFG1, PCIE_ATU_CR1);
dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
- dw_pcie_writel_rc(pp, pp-cfg1_base, PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, (pp-cfg1_base 32), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, pp-cfg1_base + pp-config.cfg1_size - 1,
+ dw_pcie_writel_rc(pp, cfg1_base, PCIE_ATU_LOWER_BASE);
+ dw_pcie_writel_rc(pp, (cfg1_base 32), PCIE_ATU_UPPER_BASE);
+ dw_pcie_writel_rc(pp, cfg1_base + pp-config.cfg1_size - 1,
PCIE_ATU_LIMIT);
dw_pcie_writel_rc(pp, busdev, PCIE_ATU_LOWER_TARGET);
dw_pcie_writel_rc(pp, 0, PCIE_ATU_UPPER_TARGET);
@@ -533,14 +542,17 @@ static void dw_pcie_prog_viewport_cfg1(struct pcie_port
*pp, u32 busdev)
static void dw_pcie_prog_viewport_mem_outbound(struct pcie_port *pp)
{
+ u64 mem_base;
+
+ mem_base = pp-mem_base pp-base_mask;
/* Program viewport 0 : OUTBOUND : MEM */
dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
PCIE_ATU_VIEWPORT);
dw_pcie_writel_rc(pp, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1
Re: [RFC PATCH 02/12] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Wednesday, March 26, 2014 10:58 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.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Hi Kishon,
Long time no see! I added trivial comments.
---
Documentation/devicetree/bindings/pci/ti-pci.txt | 35 ++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile|1 +
drivers/pci/host/pcie-dra7xx.c | 411
++
How about using 'pci-' prefix?
As it was discussed earlier, 'pci-' prefix is more proper.
4 files changed, 457 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
create mode 100644 drivers/pci/host/pcie-dra7xx.c
[.]
--- /dev/null
+++ b/drivers/pci/host/pcie-dra7xx.c
[.]
+#define PCIECTRL_TI_CONF_IRQSTATUS_MAIN 0x0024
+#define PCIECTRL_TI_CONF_IRQENABLE_SET_MAIN 0x0028
I don't think that it's good to add vendor names such as TI
to SFR names.
How about adding 'DRA7XX' or just removing 'TI'?
1. PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN
2. PCIECTRL_CONF_IRQSTATUS_MAIN
[.]
+enum dra7xx_pcie_device_type {
+ DRA7XX_PCIE_UNKNOWN_TYPE,
+ DRA7XX_PCIE_EP_TYPE,
+ DRA7XX_PCIE_LEG_EP_TYPE,
+ DRA7XX_PCIE_RC_TYPE,
+};
This driver can support only RC mode, so, these enum can be removed.
[.]
+ of_property_read_u32(node, ti,device-type, device_type);
+ switch (device_type) {
+ case DRA7XX_PCIE_RC_TYPE:
+ dra7xx_pcie_writel(dra7xx-base,
+ PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_RC);
+ break;
+ case DRA7XX_PCIE_EP_TYPE:
+ dra7xx_pcie_writel(dra7xx-base,
+ PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_EP);
+ break;
+ case DRA7XX_PCIE_LEG_EP_TYPE:
+ dra7xx_pcie_writel(dra7xx-base,
+ PCIECTRL_TI_CONF_DEVICE_TYPE, DEVICE_TYPE_LEG_EP);
+ break;
+ default:
+ dev_dbg(dev, UNKNOWN device type %d\n, device_type);
+ }
Thus, this switch can be removed.
Others look good.
Best regards,
Jingoo Han
--
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/4] power_supply: Introduce generic psy charging driver
On Wednesday, February 12, 2014 8:00 PM, Pavel Machek wrote:
On Wed 2014-02-05 13:44:58, Jenny Tc wrote:
On Tue, Feb 04, 2014 at 12:36:30PM +0100, Pavel Machek wrote:
+struct psy_charger_context {
+ bool is_usb_cable_evt_reg;
+ int psyc_cnt;
+ int batt_status;
+ /*cache battery and charger properties */
Comment coding style. Please run you patches through checkpatch.
checkpatch doesn't throw any error/warning. /* ... */ not allowed for
single line
comments? (will fix missing space after /*)
I meant the space after /*. Maybe checkpatch does not report anything
here, but I guess there are other places where it will comment :-).
Yes, right.
+ /*cache battery and charger properties */
^
'one space' is necessary between '/*' and 'cache'.
This can be fixed as below.
+ /* cache battery and charger properties */
Best regards,
Jingoo Han
--
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 4/4] power_supply: bq24261 charger driver
On Wednesday, January 29, 2014 10:24 PM, Jenny Tc wrote:
On Tue, Jan 28, 2014 at 07:14:45AM -0700, Pavel Machek wrote:
+#define BQ24261_ICHRG_MASK (0x1F 3)
+#define BQ24261_ICHRG_100ma (0x01 3)
+#define BQ24261_ICHRG_200ma (0x01 4)
+#define BQ24261_ICHRG_400ma (0x01 5)
+#define BQ24261_ICHRG_800ma (0x01 6)
+#define BQ24261_ICHRG_1600ma (0x01 7)
First, its mA, not ma.
Camel Case allowed? Ignore Checkpatch.pl warning?
Yep, Camel Case is allowed by the commit d8b0771 checkpatch:
extend CamelCase types and ignore existing CamelCase uses in
a patch.
Thus, the following cases are currently allowed.
#define BQ24261_ICHRG_1600ma (0x01 7)
#define BQ24261_ICHRG_1600MA (0x01 7)
#define BQ24261_ICHRG_1600mA (0x01 7)
Best regards,
Jingoo Han
+u16 bq24261_iterm[][2] = {
+ {0, 0x00}
+ ,
+ {50, BQ24261_ITERM_50ma}
+ ,
+ {100, BQ24261_ITERM_100ma}
+ ,
+ {150, BQ24261_ITERM_100ma | BQ24261_ITERM_50ma}
...this is very obscure way to do with table what can be done with
(x/50) 3, right ?
Few register settings need table mapping, but some can have logic as your
comment say. Just wanted to keep same logic for all register settings.
Doesn't it make more readable?
+u16 bq24261_cc[][2] = {
+
+ {500, 0x00}
+ ,
+ {600, BQ24261_ICHRG_100ma}
+ ,
+ {700, BQ24261_ICHRG_200ma}
+ ,
+ {800, BQ24261_ICHRG_100ma | BQ24261_ICHRG_200ma}
+ ,
+ {900, BQ24261_ICHRG_400ma}
I suspect you can get rid of this, too, if you expand macros.
Same as above comment.
-Jenny
--
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 4/4] power_supply: bq24261 charger driver
On Thursday, January 23, 2014 2:20 AM, Jenny TC wrote: This patch introduces BQ24261 charger driver. The driver makes use of power supply charging driver to setup charging. So the driver does hardware abstraction and handles h/w specific corner cases. The charging logic resides with power supply charging driver Signed-off-by: Jenny TC jenny...@intel.com Hi Jenny, Thank you for including me. I added some minor comments. :-) --- drivers/power/Kconfig | 10 + drivers/power/Makefile|1 + drivers/power/bq24261_charger.c | 1447 + include/linux/power/bq24261_charger.h | 33 + 4 files changed, 1491 insertions(+) create mode 100644 drivers/power/bq24261_charger.c create mode 100644 include/linux/power/bq24261_charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 655457b..3f32f61 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -408,6 +408,16 @@ config BATTERY_GOLDFISH Say Y to enable support for the battery and AC power in the Goldfish emulator. +config BQ24261_CHARGER + tristate BQ24261 charger driver + select POWER_SUPPLY_CHARGER + depends on I2C + help + Say Y to include support for BQ24261 Charger driver. This driver + makes use of power supply charging driver. So the driver gives + the charger hardware abstraction only. Charging logic is abstracted + in the power supply charging driver. + source drivers/power/reset/Kconfig endif # POWER_SUPPLY diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 77535fd..6d184c8 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_POWER_AVS) += avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o +obj-$(CONFIG_BQ24261_CHARGER)+= bq24261_charger.o obj-$(CONFIG_POWER_RESET)+= reset/ diff --git a/drivers/power/bq24261_charger.c b/drivers/power/bq24261_charger.c new file mode 100644 index 000..6ac063b --- /dev/null +++ b/drivers/power/bq24261_charger.c @@ -0,0 +1,1447 @@ +/* + * bq24261_charger.c - BQ24261 Charger I2C client driver + * + * Copyright (C) 2011 Intel Corporation + * + * ~~ + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * ~~ + * Author: Jenny TC jenny...@intel.com + */ +#define DEBUG Please insert one line between the comment and the #define. +#include linux/version.h +#include linux/kernel.h +#include linux/module.h +#include linux/err.h +#include linux/init.h +#include linux/interrupt.h +#include linux/slab.h +#include linux/device.h +#include linux/i2c.h +#include linux/power_supply.h +#include linux/pm_runtime.h +#include linux/io.h +#include linux/sched.h +#include linux/delay.h +#include linux/usb/otg.h +#include linux/power/power_supply_charger.h +#include linux/power/bq24261_charger.h +#include linux/seq_file.h Would you re-order these headers alphabetically? It enhances the readability. + +#include asm/intel_scu_ipc.h + +#define DEV_NAME bq24261_charger +#define DEV_MANUFACTURER TI +#define MODEL_NAME_SIZE 8 +#define DEV_MANUFACTURER_NAME_SIZE 4 + +#define EXCEPTION_MONITOR_DELAY (60 * HZ) +#define WDT_RESET_DELAY (15 * HZ) + +/* BQ24261 registers */ +#define BQ24261_STAT_CTRL0_ADDR 0x00 +#define BQ24261_CTRL_ADDR0x01 +#define BQ24261_BATT_VOL_CTRL_ADDR 0x02 +#define BQ24261_VENDOR_REV_ADDR 0x03 +#define BQ24261_TERM_FCC_ADDR0x04 +#define BQ24261_VINDPM_STAT_ADDR 0x05 +#define BQ24261_ST_NTC_MON_ADDR 0x06 + +#define BQ24261_RESET_MASK (0x01 7) +#define BQ24261_RESET_ENABLE (0x01 7) + +#define BQ24261_FAULT_MASK 0x07 +#define BQ24261_STAT_MASK(0x03 4) +#define BQ24261_BOOST_MASK (0x01 6) +#define BQ24261_TMR_RST_MASK (0x01 7) +#define BQ24261_TMR_RST (0x01 7) + +#define BQ24261_ENABLE_BOOST (0x01 6) + +#define BQ24261_VOVP 0x01 +#define BQ24261_LOW_SUPPLY 0x02 +#define BQ24261_THERMAL_SHUTDOWN 0x03 +#define BQ24261_BATT_TEMP_FAULT 0x04 +#define BQ24261_TIMER_FAULT 0x05
RE: [PATCH 1/4] power_supply: Add inlmt,iterm, min/max temp props
On Thursday, January 23, 2014 2:20 AM, Jenny TC wrote: Add new power supply properties for input current, charge termination current, min and max temperature POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates the input current for a charging source. POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect the end of charge condition Change-Id: Ifb40662bbfa24387ac7493ffa7ce01c6fae7e800 Please remove this 'Change-Id' from the commit message. Best regards, Jingoo Han Signed-off-by: Jenny TC jenny...@intel.com --- Documentation/power/power_supply_class.txt |6 ++ drivers/power/power_supply_sysfs.c |4 include/linux/power_supply.h |4 3 files changed, 14 insertions(+) -- 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] OMAPDSS: Add missing dependency on backlight for DSI-CM panel drier
On Wednesday, September 25, 2013 8:31 PM, Mark Brown wrote: From: Mark Brown broo...@linaro.org The DSI-CM driver uses the backlight class so needs to build depend on it. Signed-off-by: Mark Brown broo...@linaro.org Reviewed-by: Jingoo Han jg1@samsung.com I checked that the following build errors are removed. drivers/video/omap2/displays-new/panel-dsi-cm.c:1257: undefined reference to `backlight_device_register' drivers/video/omap2/displays-new/panel-dsi-cm.c:1283: undefined reference to `backlight_device_unregister' drivers/built-in.o: In function `dsicm_remove': drivers/video/omap2/displays-new/panel-dsi-cm.c:1309: undefined reference to `backlight_device_unregister' Thank you. Best regards, Jingoo Han --- drivers/video/omap2/displays-new/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/omap2/displays-new/Kconfig b/drivers/video/omap2/displays-new/Kconfig index 6c90885..10b25e7 100644 --- a/drivers/video/omap2/displays-new/Kconfig +++ b/drivers/video/omap2/displays-new/Kconfig @@ -35,6 +35,7 @@ config DISPLAY_PANEL_DPI config DISPLAY_PANEL_DSI_CM tristate Generic DSI Command Mode Panel + depends on BACKLIGHT_CLASS_DEVICE help Driver for generic DSI command mode panels. -- 1.8.4.rc3 -- 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: dwc3: Remove additional delay of 100ms when resuming
On Monday, September 23, 2013 12:38 PM, Vivek Gautam wrote: This delay got introduced in: 7415f17 usb: dwc3: core: add power management support which reflected similar code in dwc3_core_soft_reset() function. However, originally the delay of 100ms in dwc3_core_soft_reset() was meant to assist USB2PHY and USB3PHY reset, not for usb_phy_init() sequence. We should get rid of this delay, since things will still work fine without this. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Reviewed-by: Jingoo Han jg1@samsung.com OK, I see. There is no reason to add msleep(100) to dwc3_resume(); thus, this msleep(100) can be removed. Best regards, Jingoo Han --- Hi Felipe, I remember this change for phy_init including msleep(100) was suggested by me, after testing the patch-series for PM support to dwc3. Sorry for that !! drivers/usb/dwc3/core.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 474162e..e88ffae 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -691,7 +691,6 @@ static int dwc3_resume(struct device *dev) usb_phy_init(dwc-usb3_phy); usb_phy_init(dwc-usb2_phy); - msleep(100); spin_lock_irqsave(dwc-lock, flags); -- 1.7.6.5 -- 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 v9 1/8] drivers: phy: add generic PHY framework
On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. For dt-boot, the PHY drivers should also register *PHY provider* with the framework. PHY drivers should create the PHY by passing id and ops like init, exit, power_on and power_off. This framework is also pm runtime enabled. The documentation for the generic PHY framework is added in Documentation/phy.txt and the documentation for dt binding can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Tested-by: Sylwester Nawrocki s.nawro...@samsung.com Tested-by: Jingoo Han jg1@samsung.com It looks great to me! I tested this General PHY framework with Exynos5250 eDP. It works properly. I will share the patch 'Generic PHY driver for the Exynos SoC DP PHY', soon. Thanks. Best regards, Jingoo Han --- .../devicetree/bindings/phy/phy-bindings.txt | 66 +++ Documentation/phy.txt | 129 + MAINTAINERS|7 + drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 544 include/linux/phy/phy.h| 344 + 9 files changed, 1112 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h -- 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 09/42] drivers/i2c/busses: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/busses/i2c-davinci.c|6 +-
drivers/i2c/busses/i2c-designware-platdrv.c |6 +-
drivers/i2c/busses/i2c-imx.c|6 +-
drivers/i2c/busses/i2c-omap.c |6 +-
drivers/i2c/busses/i2c-rcar.c |7 +--
drivers/i2c/busses/i2c-s3c2410.c|5 -
For drivers/i2c/busses/i2c-s3c2410.c
Reviewed-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
drivers/i2c/busses/i2c-sirf.c |6 --
drivers/i2c/busses/i2c-tegra.c |5 -
8 files changed, 5 insertions(+), 42 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index cf20e06..2ed3e7b 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -647,11 +647,6 @@ static int davinci_i2c_probe(struct platform_device
*pdev)
int r;
/* NOTE: driver uses the static register mapping */
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(pdev-dev, no mem resource?\n);
- return -ENODEV;
- }
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!irq) {
@@ -697,6 +692,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
return -ENODEV;
clk_prepare_enable(dev-clk);
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev-base = devm_ioremap_resource(pdev-dev, mem);
if (IS_ERR(dev-base)) {
r = PTR_ERR(dev-base);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 8ec9133..6f3c612 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -87,11 +87,6 @@ static int dw_i2c_probe(struct platform_device *pdev)
int irq, r;
/* NOTE: driver uses the static register mapping */
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(pdev-dev, no mem resource?\n);
- return -EINVAL;
- }
irq = platform_get_irq(pdev, 0);
if (irq 0) {
@@ -103,6 +98,7 @@ static int dw_i2c_probe(struct platform_device *pdev)
if (!dev)
return -ENOMEM;
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev-base = devm_ioremap_resource(pdev-dev, mem);
if (IS_ERR(dev-base))
return PTR_ERR(dev-base);
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 82f20c6..b274ca1 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -500,17 +500,13 @@ static int __init i2c_imx_probe(struct platform_device
*pdev)
dev_dbg(pdev-dev, %s\n, __func__);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(pdev-dev, can't get device resources\n);
- return -ENOENT;
- }
irq = platform_get_irq(pdev, 0);
if (irq 0) {
dev_err(pdev-dev, can't get irq number\n);
return -ENOENT;
}
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..8498ab7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1085,11 +1085,6 @@ omap_i2c_probe(struct platform_device *pdev)
u16 minor, major, scheme;
/* NOTE: driver uses the static register mapping */
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(pdev-dev, no mem resource?\n);
- return -ENODEV;
- }
irq = platform_get_irq(pdev, 0);
if (irq 0) {
@@ -1103,6 +1098,7 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev-base = devm_ioremap_resource(pdev-dev, mem);
if (IS_ERR(dev-base))
return PTR_ERR(dev-base);
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 4ba4a95..0fc5858 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -623,12 +623,6 @@ static int rcar_i2c_probe(struct platform_device *pdev)
u32 bus_speed;
int ret;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, no mmio resources\n);
- return -ENODEV;
- }
-
priv = devm_kzalloc(dev, sizeof(struct rcar_i2c_priv), GFP_KERNEL
Re: [RFC 34/42] drivers/video/omap2/dss: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
It looks good.
Reviewed-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
drivers/video/omap2/dss/hdmi.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 17f4d55..7bc6762 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1064,13 +1064,8 @@ static int omapdss_hdmihw_probe(struct platform_device
*pdev)
mutex_init(hdmi.lock);
mutex_init(hdmi.ip_data.lock);
- res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
- if (!res) {
- DSSERR(can't get IORESOURCE_MEM HDMI\n);
- return -EINVAL;
- }
-
/* Base address taken from platform */
+ res = platform_get_resource(hdmi.pdev, IORESOURCE_MEM, 0);
hdmi.ip_data.base_wp = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(hdmi.ip_data.base_wp))
return PTR_ERR(hdmi.ip_data.base_wp);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev 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 33/42] drivers/video/omap2: don't check resource with devm_ioremap_resource
On Friday, May 10, 2013 5:17 PM, Wolfram Sang wrote:
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Reviewed-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
drivers/video/omap2/vrfb.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/video/omap2/vrfb.c b/drivers/video/omap2/vrfb.c
index 5261229..f346b02 100644
--- a/drivers/video/omap2/vrfb.c
+++ b/drivers/video/omap2/vrfb.c
@@ -353,11 +353,6 @@ static int __init vrfb_probe(struct platform_device
*pdev)
/* first resource is the register res, the rest are vrfb contexts */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(pdev-dev, can't get vrfb base address\n);
- return -EINVAL;
- }
-
vrfb_base = devm_ioremap_resource(pdev-dev, mem);
if (IS_ERR(vrfb_base))
return PTR_ERR(vrfb_base);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev 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 14/24] USB: ohci: merge ohci_finish_controller_resume with ohci_resume
On Friday, October 05, 2012 12:18 AM Florian Fainelli wrote
Merge ohci_finish_controller_resume with ohci_resume as suggested by Alan
Stern. Since ohci_finish_controller_resume no longer exists, update the
various OHCI drivers to call ohci_resume() instead. Some drivers used to set
themselves the bit HCD_FLAG_HW_ACCESSIBLE, which is now handled by
ohci_resume().
Signed-off-by: Florian Fainelli flor...@openwrt.org
For drivers/usb/host/ohci-exynos.c, it looks good.
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
---
drivers/usb/host/ohci-at91.c |2 +-
drivers/usb/host/ohci-ep93xx.c |2 +-
drivers/usb/host/ohci-exynos.c |5 +
drivers/usb/host/ohci-hcd.c | 41 +++--
drivers/usb/host/ohci-hub.c | 42
--
drivers/usb/host/ohci-omap.c |2 +-
drivers/usb/host/ohci-platform.c |2 +-
drivers/usb/host/ohci-pxa27x.c |2 +-
drivers/usb/host/ohci-s3c2410.c |3 +--
drivers/usb/host/ohci-spear.c|2 +-
drivers/usb/host/ohci-tmio.c |2 +-
11 files changed, 48 insertions(+), 57 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 0bf72f9..908d84a 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -705,7 +705,7 @@ static int ohci_hcd_at91_drv_resume(struct
platform_device *pdev)
if (!clocked)
at91_start_clock();
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#else
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index dbfbd1d..a982f04 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -194,7 +194,7 @@ static int ohci_hcd_ep93xx_drv_resume(struct
platform_device *pdev)
ep93xx_start_hc(pdev-dev);
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
#endif
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index fc3091b..53c5a989 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -252,10 +252,7 @@ static int exynos_ohci_resume(struct device *dev)
if (pdata pdata-phy_init)
pdata-phy_init(pdev, S5P_USB_PHY_HOST);
- /* Mark hardware accessible again as we are out of D3 state by now */
- set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
-
- ohci_finish_controller_resume(hcd);
+ ohci_resume(hcd, false);
return 0;
}
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 5d30992..568bdb3 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1003,13 +1003,50 @@ static int __maybe_unused ohci_suspend(struct usb_hcd
*hcd, bool do_wakeup)
static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
{
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ int port;
+ boolneed_reinit = false;
+
set_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
/* Make sure resume from hibernation re-enumerates everything */
if (hibernated)
- ohci_usb_reset(hcd_to_ohci(hcd));
+ ohci_usb_reset(ohci);
+
+ /* See if the controller is already running or has been reset */
+ ohci-hc_control = ohci_readl(ohci, ohci-regs-control);
+ if (ohci-hc_control (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
+ need_reinit = true;
+ } else {
+ switch (ohci-hc_control OHCI_CTRL_HCFS) {
+ case OHCI_USB_OPER:
+ case OHCI_USB_RESET:
+ need_reinit = true;
+ }
+ }
+
+ /* If needed, reinitialize and suspend the root hub */
+ if (need_reinit) {
+ spin_lock_irq(ohci-lock);
+ ohci_rh_resume(ohci);
+ ohci_rh_suspend(ohci, 0);
+ spin_unlock_irq(ohci-lock);
+ }
+
+ /* Normally just turn on port power and enable interrupts */
+ else {
+ ohci_dbg(ohci, powerup ports\n);
+ for (port = 0; port ohci-num_ports; port++)
+ ohci_writel(ohci, RH_PS_PPS,
+ ohci-regs-roothub.portstatus[port]);
+
+ ohci_writel(ohci, OHCI_INTR_MIE, ohci-regs-intrenable);
+ ohci_readl(ohci, ohci-regs-intrenable);
+ msleep(20);
+ }
+
+ usb_hcd_resume_root_hub(hcd);
- ohci_finish_controller_resume(hcd);
return 0;
}
diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index 2f3619e..db09dae 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -316,48 +316,6 @@ static int ohci_bus_resume (struct usb_hcd *hcd)
return rc;
}
-/* Carry out the final steps of resuming the controller device
Re: [PATCH 0/6] OMAPDSS: remove cpu_is_* calls
On Friday, September 28, 2012 7:35 PM Tomi Valkeinen wrote Hi, This series adds an omapdss_version enum that is passed via platform data to omapdss driver. This version identifier is then used instead of cpu_is_*() calls. Hi Tomi, As you mentioned, cpu_is_*() is not preferable in driver. Actually, I thought so, when I saw the OMAPDSS driver a few months ago. Anyway, it looks good. :) Best regards, Jingoo Han After these, omapdss no longer contains any plat/ or mach/ includes. omapfb, vrfb and vram still do, though. Tomi Tomi Valkeinen (6): OMAPDSS: add omapdss_version OMAPDSS: use omapdss_version in dss_features.c OMAPDSS: DISPC: use omapdss_version OMAPDSS: DSS: use omapdss_version OMAPDSS: HDMI: use omapdss_version OMAPDSS: remove plat/cpu.h includes arch/arm/mach-omap2/display.c | 38 +++ drivers/video/omap2/dss/core.c |2 +- drivers/video/omap2/dss/dispc.c| 41 +--- drivers/video/omap2/dss/dss.c | 39 +-- drivers/video/omap2/dss/dss_features.c | 64 ++-- drivers/video/omap2/dss/dss_features.h |5 ++- drivers/video/omap2/dss/hdmi.c |3 +- include/video/omapdss.h| 14 +++ 8 files changed, 157 insertions(+), 49 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-fbdev 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] OMAPDSS: HDMI: Discard phy_tx_enabled member
On Saturday 16 June 2012 7:02:00 jaswinder.singh wrote:
From: Jassi Brar jaswinder.si...@linaro.org
Explicitly maintaining HDMI phy power state using a flag is prone to
race and un-necessary when we have a zero-cost alternative of checking
the state before trying to set it.
CC'ed 'Mythri P K' as the author for OMAP HDMI.
Hi Jassi, long time no see.
This patch looks good.
If there is no problem, checking register is better way.
Best regards,
Jingoo Han.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/video/omap2/dss/ti_hdmi.h |1 -
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 11 ---
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index e734cb4..d174ca1 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -177,7 +177,6 @@ struct hdmi_ip_data {
/* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
int hpd_gpio;
- bool phy_tx_enabled;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 4dae1b2..3fa3d98 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -157,6 +157,10 @@ static int hdmi_pll_init(struct hdmi_ip_data *ip_data)
/* PHY_PWR_CMD */
static int hdmi_set_phy_pwr(struct hdmi_ip_data *ip_data, enum hdmi_phy_pwr
val)
{
+ /* Return if already the state */
+ if (REG_GET(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, 5, 4) == val)
+ return 0;
+
/* Command for power control of HDMI PHY */
REG_FLD_MOD(hdmi_wp_base(ip_data), HDMI_WP_PWR_CTRL, val, 7, 6);
@@ -241,11 +245,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd == ip_data-phy_tx_enabled) {
- spin_unlock_irqrestore(phy_tx_lock, flags);
- return 0;
- }
-
if (hpd)
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
else
@@ -257,7 +256,6 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
goto err;
}
- ip_data-phy_tx_enabled = hpd;
err:
spin_unlock_irqrestore(phy_tx_lock, flags);
return r;
@@ -327,7 +325,6 @@ void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data
*ip_data)
free_irq(gpio_to_irq(ip_data-hpd_gpio), ip_data);
hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_OFF);
- ip_data-phy_tx_enabled = false;
}
static int hdmi_core_ddc_init(struct hdmi_ip_data *ip_data)
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev 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] backlight: initialize struct backlight_properties properly
On Mon, May 21, 2012 at 04:25 PM +, Corentin Chary wrote: In all these files, the .power field was never correctly initialized. Signed-off-by: Corentin Chary corentin.ch...@gmail.com It looks good. Best regards, Jingoo Han --- drivers/gpu/drm/i915/intel_panel.c |1 + drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + drivers/platform/x86/toshiba_acpi.c |1 + drivers/video/backlight/da903x_bl.c |1 + drivers/video/backlight/pcf50633-backlight.c|1 + drivers/video/backlight/wm831x_bl.c |1 + drivers/video/omap2/displays/panel-acx565akm.c |1 + 7 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 48177ec..ec4a1e0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev) else return -ENODEV; + memset(props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; props.max_brightness = intel_panel_get_max_backlight(dev); dev_priv-backlight = diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c index 42db254..a0c8222 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c @@ -369,6 +369,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder, goto error; } + memset(props, 0, sizeof(props)); props.max_brightness = MAX_RADEON_LEVEL; props.type = BACKLIGHT_RAW; bd = backlight_device_register(radeon_bl, drm_connector-kdev, diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index bde32de..d680bb2 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -1095,6 +1095,7 @@ static int __devinit toshiba_acpi_setup_backlight(struct toshiba_acpi_dev *dev) ret = get_tr_backlight_status(dev, enabled); dev-tr_backlight_supported = !ret; + memset(props, 0, sizeof(props)); props.type = BACKLIGHT_PLATFORM; props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1; diff --git a/drivers/video/backlight/da903x_bl.c b/drivers/video/backlight/da903x_bl.c index 30e1968..573c7ec 100644 --- a/drivers/video/backlight/da903x_bl.c +++ b/drivers/video/backlight/da903x_bl.c @@ -136,6 +136,7 @@ static int da903x_backlight_probe(struct platform_device *pdev) da903x_write(data-da903x_dev, DA9034_WLED_CONTROL2, DA9034_WLED_ISET(pdata-output_current)); + memset(props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; props.max_brightness = max_brightness; bl = backlight_device_register(pdev-name, data-da903x_dev, data, diff --git a/drivers/video/backlight/pcf50633-backlight.c b/drivers/video/backlight/pcf50633-backlight.c index c65853c..c092159 100644 --- a/drivers/video/backlight/pcf50633-backlight.c +++ b/drivers/video/backlight/pcf50633-backlight.c @@ -111,6 +111,7 @@ static int __devinit pcf50633_bl_probe(struct platform_device *pdev) if (!pcf_bl) return -ENOMEM; + memset(bl_props, 0, sizeof(bl_props)); bl_props.type = BACKLIGHT_RAW; bl_props.max_brightness = 0x3f; bl_props.power = FB_BLANK_UNBLANK; diff --git a/drivers/video/backlight/wm831x_bl.c b/drivers/video/backlight/wm831x_bl.c index 5d365de..9e5517a 100644 --- a/drivers/video/backlight/wm831x_bl.c +++ b/drivers/video/backlight/wm831x_bl.c @@ -194,6 +194,7 @@ static int wm831x_backlight_probe(struct platform_device *pdev) data-current_brightness = 0; data-isink_reg = isink_reg; + memset(props, 0, sizeof(props)); props.type = BACKLIGHT_RAW; props.max_brightness = max_isel; bl = backlight_device_register(wm831x, pdev-dev, data, diff --git a/drivers/video/omap2/displays/panel-acx565akm.c b/drivers/video/omap2/displays/panel- acx565akm.c index d26f37a..74e7cf0 100644 --- a/drivers/video/omap2/displays/panel-acx565akm.c +++ b/drivers/video/omap2/displays/panel-acx565akm.c @@ -532,6 +532,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev) /*--- Backlight control */ + memset(props, 0, sizeof(props)); props.fb_blank = FB_BLANK_UNBLANK; props.power = FB_BLANK_UNBLANK; props.type = BACKLIGHT_RAW; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-fbdev 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: [GIT PULL] OMAP DSS fixes for 3.3-rc
Hi. -Original Message- From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-ow...@vger.kernel.org] On Behalf Of Florian Tobias Schandinat Sent: Wednesday, February 29, 2012 1:03 AM To: Tomi Valkeinen Cc: linux-fb...@vger.kernel.org; linux-omap mailing list Subject: Re: [GIT PULL] OMAP DSS fixes for 3.3-rc On 02/23/2012 09:22 AM, Tomi Valkeinen wrote: Hi Florian, Two fixes for OMAP DSS for 3.3: First one gets the HDMI output working again. Managing the clocks for OMAP4 is not very simple, and this patch circumvents the problems we have in the clock framework. It's a clean but rather hacky fix, but it shouldn't cause any side-effects. The issue will hopefully be fixed properly with DT when we'll get proper parent-child hierarchy for DSS HW submodules. The second one is a simple fix for HDMI hotplug detection, which I missed when I wrote the HDMI PHY fix (c49d005b6cc8491fad5b24f82805be2d6bcbd3dd). Merged. You would add Cc: sta...@vger.kernel.org to patches if appropriate? I agree on Florian's opinion. It would be good to add this patch to stable kernel. :) Thanks, Florian Tobias Schandinat Tomi The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d: Linux 3.3-rc3 (2012-02-08 19:21:53 -0800) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git for-3.3-rc Archit Taneja (1): OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled Rob Clark (1): OMAPDSS: HDMI: hot plug detect fix drivers/video/omap2/dss/hdmi.c| 24 +++- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |9 + 2 files changed, 24 insertions(+), 9 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-fbdev 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: [GIT PULL] OMAP DSS fixes for 3.3-rc
-Original Message- From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev-ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen Sent: Wednesday, February 29, 2012 1:08 AM To: Florian Tobias Schandinat Cc: linux-fb...@vger.kernel.org; linux-omap mailing list Subject: Re: [GIT PULL] OMAP DSS fixes for 3.3-rc On Tue, 2012-02-28 at 16:03 +, Florian Tobias Schandinat wrote: On 02/23/2012 09:22 AM, Tomi Valkeinen wrote: Hi Florian, Two fixes for OMAP DSS for 3.3: First one gets the HDMI output working again. Managing the clocks for OMAP4 is not very simple, and this patch circumvents the problems we have in the clock framework. It's a clean but rather hacky fix, but it shouldn't cause any side-effects. The issue will hopefully be fixed properly with DT when we'll get proper parent-child hierarchy for DSS HW submodules. The second one is a simple fix for HDMI hotplug detection, which I missed when I wrote the HDMI PHY fix (c49d005b6cc8491fad5b24f82805be2d6bcbd3dd). Merged. You would add Cc: sta...@vger.kernel.org to patches if appropriate? Thanks. Yes, I have sent a separate mail to stable list, as the patches needed some tuning to apply. Tomi, sorry. You have already sent a mail to sta...@vger.kernel.org. Good luck. Best regards, Jingoo Han Tomi -- 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
