Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Brian, On 27/10/15 11:37, Roger Quadros wrote: > Hi Brian, > > On 26/10/15 23:23, Brian Norris wrote: >> Hi Roger, >> >> I'm not too familiar with OMAP platforms, and I might have missed out on >> prior discussions/context, so please forgive if I'm asking silly or old >> questions here. > > No worries at all. > >> >> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote: >>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ >>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver. >>> This causes performance increase when using prefetch-irq mode. >>> 30% increase in read, 17% increase in write in prefetch-irq mode. >> >> Have you pinpointed the exact causes for the performance increase, or >> can you give an educated guess? AIUI, you're reducing the number of >> interrupts needed for NAND prefetch mode, but you're also removing a bit >> of abstraction and implementing hooks that look awfully like the >> existing abstractions: >> >> + int (*nand_irq_enable)(enum gpmc_nand_irq irq); >> + int (*nand_irq_disable)(enum gpmc_nand_irq irq); >> + void (*nand_irq_clear)(enum gpmc_nand_irq irq); >> + u32 (*nand_irq_status)(void); >> >> That's not really a problem if there's a good reason for them (brcmnand >> implements similar hooks because of quirks in the implementation of >> interrupts across various BRCM SoCs, and it's not worth writing irqchip >> drivers for those cases). I'm mainly curious for an explanation. > > I have both implementations with me. My guess is that the 20% performance > gain is due to absence of irqchip/irqdomain translation code. > I haven't investigated further though. > > Another concern I have is that I'm not using any locking around > gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND > use cases? My understanding is that it should not as the controller access > is serialized between multiple NAND chips. > > However I do need to add some locking as the GPMC_IRQENABLE register is shared > between NAND and GPMC driver. > > NOTE: We are not using prefetch-irq mode for any of the OMAP boards because > of lesser performance than prefetch-polled mode. So if the less performance > for an unused mode is a lesser concern compared to cleaner code then > I can resend this with the irqdomain implementation. > > Below are performance logs of irqdomain vs hooks. Any further comments? cheers, -roger > > -- > cheers, > -roger > > test logs. > > for-v4.4/gpmc-v2 - irqdomain with prefetch-irq. No ready pin. > > > [ 67.696631] > [ 67.698201] = > [ 67.704254] mtd_speedtest: MTD device: 8 > [ 67.708373] mtd_speedtest: MTD device size 8388608, eraseblock size > 131072, page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB > size 64 > [ 67.723701] mtd_test: scanning for bad eraseblocks > [ 67.735468] mtd_test: scanned 64 eraseblocks, 0 are bad > [ 67.772861] mtd_speedtest: testing eraseblock write speed > [ 70.372903] mtd_speedtest: eraseblock write speed is 3156 KiB/s > [ 70.379104] mtd_speedtest: testing eraseblock read speed > [ 72.594169] mtd_speedtest: eraseblock read speed is 3708 KiB/s > [ 72.656375] mtd_speedtest: testing page write speed > [ 75.213646] mtd_speedtest: page write speed is 3208 KiB/s > [ 75.219311] mtd_speedtest: testing page read speed > [ 77.343639] mtd_speedtest: page read speed is 3865 KiB/s > [ 77.405236] mtd_speedtest: testing 2 page write speed > [ 80.039702] mtd_speedtest: 2 page write speed is 3114 KiB/s > [ 80.045561] mtd_speedtest: testing 2 page read speed > [ 82.175098] mtd_speedtest: 2 page read speed is 3856 KiB/s > [ 82.180849] mtd_speedtest: Testing erase speed > [ 82.241548] mtd_speedtest: erase speed is 146285 KiB/s > [ 82.246920] mtd_speedtest: Testing 2x multi-block erase speed > [ 82.284789] mtd_speedtest: 2x multi-block erase speed is 264258 KiB/s > [ 82.291551] mtd_speedtest: Testing 4x multi-block erase speed > [ 82.329358] mtd_speedtest: 4x multi-block erase speed is 264258 KiB/s > [ 82.336116] mtd_speedtest: Testing 8x multi-block erase speed > [ 82.373903] mtd_speedtest: 8x multi-block erase speed is 264258 KiB/s > [ 82.380648] mtd_speedtest: Testing 16x multi-block erase speed > [ 82.418503] mtd_speedtest: 16x multi-block erase speed is 264258 KiB/s > [ 82.425356] mtd_speedtest: Testing 32x multi-block erase speed > [ 82.463227] mtd_speedtest: 32x multi-block erase speed is 264258 KiB/s > [ 82.470066] mtd_speedtest: Testing 64x multi-block erase speed > [ 82.507908] mtd_speedtest: 64x multi-block erase speed is 264258 KiB/s > [ 82.514758] mtd_speedtest: finished > [ 82.518417] = > > root@rockdesk:~# cat /proc/interrupts >CPU0 CPU1 > 324: 798720 0 CBAR 15 Level gpmc > 397: 798720 0 gpmc
Re: [PATCH 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO
Hi,
On 03/09/15 10:39, Roger Quadros wrote:
> On 28/07/15 14:34, Roger Quadros wrote:
>> Paul,
>>
>> On 16/07/15 16:56, Roger Quadros wrote:
>>> On 16/07/15 04:25, Paul Walmsley wrote:
Hi
On Tue, 23 Jun 2015, Roger Quadros wrote:
> For some hwmods (e.g. DCAN on DRA7) we need the possibility to
> disable HW_AUTO for the clockdomain while the module is active.
>
> To achieve this there needs to be a refcounting mechanism to
> indicate whether any module in the clockdomain has requested
> to disable HW_AUTO. We keep track of this in 'noidlecount'.
>
> Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
> HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.
>
> It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
> the future clkdm_hwmod_hwauto() calls.
>
> Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
> to request HW_AUTO of any clockdomain. (Typically after it has
> enabled the module).
How about just modifying clkdm_{allow,deny}_idle*() to do the
idle-block-counting? The default state would be to allow idle, assuming
that the clockdomain flags support that state, and then clkdm_deny_idle*()
would increment the idle-blocking count, clkdm_allow_idle*() would
decrement it. Then on the 0 -> 1 or 1 -> 0 transitions, the hardware
would be reprogrammed appropiately.
>>>
>>> That is not possible with current hwmod code as clkdm_allow_idle() and
>>> clkdm_deny_idle()
>>> are not symmetrically placed.
>>>
>>> The usual flow is
>>> clkdm_enable_hwmod();
>>> if (hwsup)
>>> clkdm_allow_idle();
>>>
>>> This is mainly because it is redundant to disable auto idle before enableing
>>> (SW_WKUP) the clockdomain.
>>>
>>> If we take your proposal above then we have to modify all users like so.
>>>
>>> if (hwsup)
>>> clkdm_deny_idle();
>>> clkdm_enable_hwmod();
>>> if (hwsup)
>>> clkdm_allow_idle();
>>>
>>> Is this really what we want?
>>
>> Any comments on this?
>
> Paul. I'm waiting on your input to rework this series if needed.
> Early input would be much appreciated. Thanks.
Not sure if Paul is receiving my e-mails but I'd like
others to give their opinion on how we can proceed with this. Thanks.
cheers,
-roger
>
>>
>>>
Anyway, seems like that would avoid races with any
clkdm_{allow,deny}_idle*() users.
A few other comments below:
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/clockdomain.c | 71
> +++
> arch/arm/mach-omap2/clockdomain.h | 5 +++
> 2 files changed, 76 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/clockdomain.c
> b/arch/arm/mach-omap2/clockdomain.c
> index 2da3b5e..a7190d2 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -1212,6 +1212,77 @@ ccd_exit:
> return 0;
> }
>
> +/*
> + * prevent future hwauto for this clkdm. If clkdm->usecount becomes
> hwauto isn't prevented.
> + * It will only prevnt future hwauto but not bring it out of hwauto.
> + */
If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue
- but all of the function comments should be fixed so that they are
understandable and follow kernel-doc-nano specs.
>>>
>>> OK for updating the comments.
>>>
>>>
>>> cheers,
>>> -roger
>>>
> +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct
> omap_hwmod *oh)
> +{
> + /* The clkdm attribute does not exist yet prior OMAP4 */
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + return 0;
> +
> + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
> + return -EINVAL;
> +
> +
> + pwrdm_lock(clkdm->pwrdm.ptr);
> + clkdm->noidlecount++;
> + pwrdm_unlock(clkdm->pwrdm.ptr);
> +
> + return 0;
> +}
> +
> +/*
> + * allow future hwauto for this clkdm
> + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that.
> + */
> +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct
> omap_hwmod *oh)
> +{
> + /* The clkdm attribute does not exist yet prior OMAP4 */
> + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> + return 0;
> +
> + if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
> + return -EINVAL;
> +
> +
> + pwrdm_lock(clkdm->pwrdm.ptr);
> +
> + if (clkdm->noidlecount == 0) {
> + pwrdm_unlock(clkdm->pwrdm.ptr);
> + WARN_ON(1); /* underflow */
> + return -ERANGE;
> + }
> +
> + clkdm->noidlecount--;
> + pwrdm_unlock(clkdm->pwrdm.ptr);
> +
> + return 0;
> +}
> +
> +/*
> + * put clkdm in hwauto if we
Re: [rtc-linux] [PATCH] rtc: ds1307: fix kernel splat due to wakeup irq handling
On 11/11/2015 at 10:11:01 -0600, Felipe Balbi wrote :
> Since commit 3fffd1283927 ("i2c: allow specifying
> separate wakeup interrupt in device tree") we have
> automatic wakeup irq support for i2c devices. That
> commit missed the fact that rtc-1307 had its own
> wakeup irq handling and ended up introducing a
> kernel splat for at least Beagle x15 boards.
>
> Fix that by reverting original commit _and_ passing
> correct interrupt names on DTS so i2c-core can
> choose correct IRQ as wakeup.
>
> Now that we have automatic wakeirq support, we can
> revert the original commit which did it manually.
>
> Fixes the following warning:
>
> [ 10.346582] WARNING: CPU: 1 PID: 263 at
> linux/drivers/base/power/wakeirq.c:43 dev_pm_attach_wake_irq+0xbc/0xd4()
> [ 10.359244] rtc-ds1307 2-006f: wake irq already initialized
>
> Cc: Tony Lindgren
> Cc: Nishanth Menon
> Signed-off-by: Felipe Balbi
> ---
> arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 +
> drivers/rtc/rtc-ds1307.c| 36
> +++--
> 2 files changed, 4 insertions(+), 33 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] regulator: tps65218: add support for LS3 current regulator
Add support for TPS65218 LS3 current regulator, which is capable of 4
current input limit modes: 100, 200, 500, and 1000 uA.
Signed-off-by: Nikita Kiryanov
Cc: Tony Lindgren
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Samuel Ortiz
Cc: Lee Jones
---
drivers/regulator/tps65218-regulator.c | 137 +
include/linux/mfd/tps65218.h | 7 +-
include/linux/regulator/driver.h | 2 +
3 files changed, 115 insertions(+), 31 deletions(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 7f97223..d88eb57 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -27,19 +27,22 @@
#include
#include
-enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5, DCDC6, LDO1 };
+enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4,
+ DCDC5, DCDC6, LDO1, LS3 };
-#define TPS65218_REGULATOR(_name, _id, _ops, _n, _vr, _vm, _er, _em, \
- _lr, _nlr, _delay, _fuv)\
+#define TPS65218_REGULATOR(_name, _id, _type, _ops, _n, _vr, _vm, _er, _em, \
+ _cr, _cm, _lr, _nlr, _delay, _fuv) \
{ \
.name = _name,\
.id = _id, \
.ops= &_ops,\
.n_voltages = _n, \
- .type = REGULATOR_VOLTAGE,\
+ .type = _type,\
.owner = THIS_MODULE, \
.vsel_reg = _vr, \
.vsel_mask = _vm, \
+ .csel_reg = _cr, \
+ .csel_mask = _cm, \
.enable_reg = _er, \
.enable_mask= _em, \
.volt_table = NULL, \
@@ -80,6 +83,7 @@ static struct tps_info tps65218_pmic_regs[] = {
TPS65218_INFO(DCDC5, "DCDC5", 100, 100),
TPS65218_INFO(DCDC6, "DCDC6", 180, 180),
TPS65218_INFO(LDO1, "LDO1", 90, 340),
+ TPS65218_INFO(LS3, "LS3", -1, -1),
};
#define TPS65218_OF_MATCH(comp, label) \
@@ -96,6 +100,7 @@ static const struct of_device_id tps65218_of_match[] = {
TPS65218_OF_MATCH("ti,tps65218-dcdc5", tps65218_pmic_regs[DCDC5]),
TPS65218_OF_MATCH("ti,tps65218-dcdc6", tps65218_pmic_regs[DCDC6]),
TPS65218_OF_MATCH("ti,tps65218-ldo1", tps65218_pmic_regs[LDO1]),
+ TPS65218_OF_MATCH("ti,tps65218-ls3", tps65218_pmic_regs[LS3]),
{ }
};
MODULE_DEVICE_TABLE(of, tps65218_of_match);
@@ -175,6 +180,68 @@ static struct regulator_ops tps65218_ldo1_dcdc34_ops = {
.map_voltage= regulator_map_voltage_linear_range,
};
+static const int ls3_currents[] = { 100, 200, 500, 1000 };
+
+static int tps65218_pmic_set_input_current_lim(struct regulator_dev *dev,
+ int lim_uA)
+{
+ unsigned int index = 0;
+ unsigned int num_currents = ARRAY_SIZE(ls3_currents);
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+
+ while (index < num_currents && ls3_currents[index] != lim_uA)
+ index++;
+
+ if (index == num_currents)
+ return -EINVAL;
+
+ return tps65218_set_bits(tps, dev->desc->csel_reg, dev->desc->csel_mask,
+index << 2, TPS65218_PROTECT_L1);
+}
+
+static int tps65218_pmic_set_current_limit(struct regulator_dev *dev,
+ int min_uA, int max_uA)
+{
+ int index = 0;
+ unsigned int num_currents = ARRAY_SIZE(ls3_currents);
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+
+ while (index < num_currents && ls3_currents[index] < max_uA)
+ index++;
+
+ index--;
+
+ if (index < 0 || ls3_currents[index] < min_uA)
+ return -EINVAL;
+
+ return tps65218_set_bits(tps, dev->desc->csel_reg, dev->desc->csel_mask,
+index << 2, TPS65218_PROTECT_L1);
+}
+
+static int tps65218_pmic_get_current_limit(struct regulator_dev *dev)
+{
+ int retval;
+ unsigned int index;
+ struct tps65218 *tps = rdev_get_drvdata(dev);
+
+ retval = tps65218_reg_read(tps, dev->desc->csel_reg, &index);
+ if (retval < 0)
+ return retval;
+
+ index = (index & dev->desc->csel_mask) >> 2;
+
+ return ls3_currents[index];
+}
+
+static struct regulator_ops tps65218_ls3_ops = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = tps65218_pmic_enable,
+ .di
Re: Clock usbhost_48m_fck didn't enable in 100000 tries and crash
Hi Michael, Thanks for the help, The clock_summary is not there but I found these files: $ pwd /sys/kernel/debug/clock/virt_26m_ck/osc_sys_ck/sys_ck/dpll4_ck/dpll4_m2_ck/dpll4_m2x2_ck/omap_96m_alwon_fck/cm_96m_fck/omap_48m_fck/usbhost_48m_fck $ cat flags 0x $ cat flags rate usecount $ cat rate 4800 $ cat usecount 1 $ Regards, - dhs 2015-11-24 17:32 GMT-02:00 Michael Trimarchi : > Hi > > Do you have /sys/kernel/debug/clk/clock_summary? > > Michael > > On Tue, Nov 24, 2015 at 7:50 PM, Daniel. wrote: >> Doing some printk mess I found that the usbhost_48m_fck is enabled. So >> my problem should be another thing: >> >> clock.c:omap2_dflt_clk_enable@193: usbhost_48m_fck enable_reg value 0x01 >> >> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi : >>> Hi >>> >>> Can you check if you have this patch in? >>> >>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2 >>> Author: Paul Walmsley >>> Date: Fri Jul 24 19:44:06 2009 -0600 >>> >>> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB >>> >>> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS, >>> USBHOST, and HSOTGUSB devices. These devices are both interconnect >>> initiators and targets. Without this patch, clk_enable()s on clocks for >>> these modules can be very high latency (potentially up to ~200 >>> milliseconds) and message such as the following are generated: >>> >>> Clock usbhost_48m_fck didn't enable in 10 tries >>> >>> Two bugs are fixed by this patch. First, OMAP hardware only supports >>> target CM_IDLEST register bits on ES2+ chips and beyond. ES1 chips >>> should not wait for these clocks to enable. So, split the appropriate >>> clocks into ES1 and ES2+ variants, so that kernels running on ES1 >>> devices won't try to wait. >>> >>> Second, the current heuristic in omap2_clk_dflt_find_idlest() will >>> fail for these clocks. It assumes that the CM_IDLEST bit to wait upon >>> is the same as the CM_*CLKEN bit, which is false[1]. Fix by >>> implementing custom clkops .find_idlest function pointers for the >>> appropriate clocks that return the correct slave IDLEST bit shift. >>> >>> This was originally fixed in the linux-omap kernel during 2.6.29 in a >>> slightly different manner[2][3]. >>> >>> >>> On Mon, Nov 23, 2015 at 9:06 PM, Daniel. wrote: Hi, Building as built-in doesn't solve my problem. The difference is that when compiled as module the dump shows up when I load it, and when is built-in the dump shows up at boot time. Also when built-in the problem seems to ocurr when device is reseted (on ehci_omap_stop) and the first stack dump is followed by much more other dumps. At the end I can see something like: "Fixing recursive fault but reboot is needed!" Here is the module info: root@csi:~# modinfo ehci-hcd filename: /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko author: Felipe Balbi author: Texas Instruments, Inc. alias: platform:omap-ehci license:GPL author: David Brownell description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver srcversion: B282C11CACFB9E75921367C depends: vermagic: 2.6.37+ mod_unload modversions ARMv7 parm: log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int) parm: park:park setting; 1-3 back-to-back async packets (uint) parm: ignore_oc:ignore bogus hardware overcurrent indications (bool) parm: hird:host initiated resume duration, +1 for each 75us (int) root@csi:~# Best regards, 2015-11-23 17:55 GMT-02:00 Michael Trimarchi : > Hi > > On Mon, Nov 23, 2015 at 8:05 PM, Daniel. wrote: >> Hi Michael, >> >> It's a plain linux. I'm considering upgrading kernel as last option. >> Variscite doesn't >> support another kernel for this SoM so this would be a really hard >> work. I'm looking >> for a solution on this kernel and mainly trying to understand why >> usbhost_48m_fck >> is not getting enabled. I'm contacting Variscite in parallel. >> > > Can you point me to te module description? I think that the module > is working if it's compiled in. Correct? > > Michael > > >> Thanks for your reply, best regards! >> >> 2015-11-23 16:57 GMT-02:00 Michael Trimarchi >> : >>> Hi Daniel >>> >>> >>> On Mon, Nov 23, 2015 at 7:45 PM, Daniel. wrote: Hi every body! I'm running a (2.6.37) kernel based on linux-omap tree (http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary). The board is a SoM from Variscite (var-som-am3517). I've compiled the ehci-hcd as a module. When I enable it I got this dump: http
Re: [PATCH 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO
* Roger Quadros [151125 02:52]:
>
> On 03/09/15 10:39, Roger Quadros wrote:
> > On 28/07/15 14:34, Roger Quadros wrote:
> >> Paul,
> >>
> >> On 16/07/15 16:56, Roger Quadros wrote:
> >>> On 16/07/15 04:25, Paul Walmsley wrote:
> Hi
>
> On Tue, 23 Jun 2015, Roger Quadros wrote:
>
> > For some hwmods (e.g. DCAN on DRA7) we need the possibility to
> > disable HW_AUTO for the clockdomain while the module is active.
> >
> > To achieve this there needs to be a refcounting mechanism to
> > indicate whether any module in the clockdomain has requested
> > to disable HW_AUTO. We keep track of this in 'noidlecount'.
> >
> > Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
> > HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.
> >
> > It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
> > the future clkdm_hwmod_hwauto() calls.
> >
> > Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
> > to request HW_AUTO of any clockdomain. (Typically after it has
> > enabled the module).
>
> How about just modifying clkdm_{allow,deny}_idle*() to do the
> idle-block-counting? The default state would be to allow idle, assuming
> that the clockdomain flags support that state, and then
> clkdm_deny_idle*()
> would increment the idle-blocking count, clkdm_allow_idle*() would
> decrement it. Then on the 0 -> 1 or 1 -> 0 transitions, the hardware
> would be reprogrammed appropiately.
> >>>
> >>> That is not possible with current hwmod code as clkdm_allow_idle() and
> >>> clkdm_deny_idle()
> >>> are not symmetrically placed.
> >>>
> >>> The usual flow is
> >>> clkdm_enable_hwmod();
> >>> if (hwsup)
> >>> clkdm_allow_idle();
> >>>
> >>> This is mainly because it is redundant to disable auto idle before
> >>> enableing
> >>> (SW_WKUP) the clockdomain.
> >>>
> >>> If we take your proposal above then we have to modify all users like so.
> >>>
> >>> if (hwsup)
> >>> clkdm_deny_idle();
> >>> clkdm_enable_hwmod();
> >>> if (hwsup)
> >>> clkdm_allow_idle();
> >>>
> >>> Is this really what we want?
> >>
> >> Any comments on this?
> >
> > Paul. I'm waiting on your input to rework this series if needed.
> > Early input would be much appreciated. Thanks.
>
> Not sure if Paul is receiving my e-mails but I'd like
> others to give their opinion on how we can proceed with this. Thanks.
Well in the long run we want to have a proper bus driver for each interconnect
instance and use genpd. I'm afraid that solution is not going to help
immediately though.
Regards,
Tony
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
* Pali Rohár [151123 06:46]: > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote: > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote: > > > Adding devicetree list. > > > > > > Thread starts at > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html > > > > > > On 11/5/2015 8:17 AM, Tony Lindgren wrote: > > > > * Pali Rohár [151105 03:41]: > > > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: > > > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: > > > * Pali Rohár [151012 13:29]: > > > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > > > >> > > > >> Pali, any news on posting an updated series with the comments > > > >> addressed in this thread? It seems that we all pretty much agree > > > >> what needs to be done. > > > > > > I'm not real happy with the concept of patches 4 and 5 in this series. > > > My concern is that those two patches are using the FDT as a transport > > > mechanism for a binary blob (the atags object). > > > > Umm. Ok. Do you have alternative proposal that works for everyone? > > > > I mean. This discussion was going for quite a long time, and it would > > be nice to have some solution... patch proposal... something. > > Pavel > > Yes, discussion is going for a long time! So should I spend time for > adding documentation to my solution (this is last one thing which is > missing)? Or my solution is wrong and somebody else will propose new? > I do not want to spend time on something which will be rejected and > discarded. At least I don't have better solutions in mind. Regards, Tony -- 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] ARM: omap2plus_defconfig: enable REGULATOR_FIXED_VOLTAGE
* Grygorii Strashko [151105 08:45]: > Enable REGULATOR_FIXED_VOLTAGE otherwise system can't boot from > SD-card when kernel is buit with CONFIG_SOC_DRA7XX=y only. > > It's also required for almost all other TI SoC's platforms. This is already enabled by default when you do make omap2plus_defconfig? Regards, Tony > Signed-off-by: Grygorii Strashko > --- > arch/arm/configs/omap2plus_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/omap2plus_defconfig > b/arch/arm/configs/omap2plus_defconfig > index 3f15a5c..6b4be64 100644 > --- a/arch/arm/configs/omap2plus_defconfig > +++ b/arch/arm/configs/omap2plus_defconfig > @@ -286,6 +286,7 @@ CONFIG_REGULATOR_TPS65217=y > CONFIG_REGULATOR_TPS65218=y > CONFIG_REGULATOR_TPS65910=y > CONFIG_REGULATOR_TWL4030=y > +CONFIG_REGULATOR_FIXED_VOLTAGE=y > CONFIG_FB=y > CONFIG_FIRMWARE_EDID=y > CONFIG_FB_MODE_HELPERS=y > -- > 2.6.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 v4 0/3] ARM: OMAP2+ McASP(3) support for DRA7xx family
* Peter Ujfalusi [151123 23:39]: > Tony, > > On 11/12/2015 08:00 PM, Tony Lindgren wrote: > > * Peter Ujfalusi [15 23:33]: > >> Hi Tony, > >> > >> Changes since v3: > >> - rebased on mainline's HEAD > >> - Added Tested-by from Felipe > >> - Added Acked-by from Paul for the hwmod patches > >> > >> Changes since v2: > >> - DTS patch added which is needed because of the clock handling changes > >> > >> Felip Balbi reported that linux-next is broken right now since the DTS > >> part of > >> the earlier series has been applied, but we do not have the mcasp hwmod in > >> the > >> kernel: > >> ... > >> [0.181029] platform 48468000.mcasp: Cannot lookup hwmod 'mcasp3' > >> ... > >> [6.121072] davinci-mcasp 48468000.mcasp: _od_fail_runtime_resume: > >> FIXME: missing hwmod/omap_dev info > >> [6.130790] [ cut here ] > >> [6.135643] WARNING: CPU: 0 PID: 244 at drivers/bus/omap_l3_noc.c:147 > >> l3_interrupt_handler+0x220/0x34c() > >> [6.145576] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER2_P3 > >> (Read): Data Access in User mode during Functional access > > > > > > Thanks applying all three into omap-for-v4.4/fixes. > > Do you know when these patches are going to be merged to mainline? 4.4-rc2 is > out, but it does not include them. Sorry for the delays, hoping to send out the fixes today or Friday after scanning emails one more time for more fixes. Regards, Tony -- 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: am35xx memory management issues
* Markku Ahvenjärvi [151124 05:57]: > On 13.11.2015 15:05, Markku Ahvenjärvi wrote: > > On 12.11.2015 19:06, Tony Lindgren wrote: > >> > >> Also please check if leaving out CONFIG_SMP_ON_UP affects things. > > > > Alright, will do. > > We've been testing omap2plus defconfig without other omaps and without > CONFIG_SMP_ON_UP. So far we haven't seen any panics, but I've had only a few > units testing it. OK > Meanwhile we've been testing our custom board with a configuration that is > quite close to omap2plus, including other omaps and CONFIG_SMP_ON_UP. We've > had couple of panics, so it seems that these doesn't affect the problem. We > had 15 units running stress-ng and it took ~8 days until we saw first panic, > so if omap2plus is affected it is quite rare. Hmm so to confirm.. Is omap2plus_defconfig stable on all boards including your custom board? > Any other suggestions? Maybe provide output of what changes make the problem happen with your custom .config if you have not already done: $ make savedefconfig $ cp defconfig arch/arm/configs/omap2plus_defconfig $ git diff Regards, Tony -- 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 01/39] pinctrl: Move am4372 and dra7 macros to the the SoC header files
Linus, * Tony Lindgren [151118 16:25]: > * Javier Martinez Canillas [151117 05:51]: > > Hello Linus, > > > > On 11/17/2015 10:47 AM, Linus Walleij wrote: > > > On Fri, Nov 13, 2015 at 5:53 AM, Javier Martinez Canillas > > > wrote: > > > > > >> The header file defines a set of macros > > >> for different SoCs families that falls under the OMAP sub-arch, that > > >> allow to define the padconf register physical address instead of the > > >> register offset from the padconf base. > > >> > > >> But the am43xx and dra7xx SoCs families have their own pinctrl header > > >> file so the DTS using these SoCs aren't able to use the AM4372_IOPAD() > > >> and DRA7XX_CORE_IOPAD() macros since is > > >> not included. > > >> > > >> Move the macros to the correct header files so can be used by the DTS. > > >> > > >> Signed-off-by: Javier Martinez Canillas > > > > > > I need Tony's ACK on this. > > > > > > > OK, I believe he was waiting for yours to pick the series though ;) > > Yeah probably best to keep this series together if you're OK with that. Care to ack this one? I'd like to apply this series for v4.5 within next few days.. Regards, Tony -- 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: power states transitions
* Ran Shalit [151122 07:59]: > Hello, > > I have stranhe behaviour in which even when there is no activity in > serial port, the retention counter is keep incremented all these time, > as if the cpu gets in and out of retention periodically. > I would expect the cpu to get into retention mode, when there is no > activity and stay in that state. > What can cause such behaviour ? Is it because some background process ? Sounds like your device is hitting deper idle states during idle. If you want to disable that, set the UART autosuspend_delay_ms to -1: #/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d) for uart in $uarts; do echo -1 > $uart/autosuspend_delay_ms 2>&1 done The above will keep the UARTs active blocking any deeper idle states. I believe the value has to be -1 instead of 0 to disable autoidle.. but please verify yourself. > My original problem is that the ethernet performance is very low with > small windows. I thought that I can control this value by changing > sleep_latency parameter in > the following array. Yet, it did not help me. I don't know why. Maybe test if the above script helps with the Ethernet too. If the Ethernet controller is on GPMC, it's not blocking deeper idle states automatically in hardware. Adding DMA support to the Ethernet driver would be a good way to block deeper idle states automatically by the Ethernet hardware. Regards, Tony -- 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 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data
* Neil Armstrong [151113 08:30]:
> Add missing HWMOD_NO_IDLEST hwmod flag for entries not
> having omap4 clkctrl values.
> The emac0 hwmod flag fixes the davinci_emac driver probe
> since the return of pm_resume() call is now checked.
>
> This solves the following boot errors :
> [0.121429] omap_hwmod: l4_ls: _wait_target_ready failed: -16
> [0.121441] omap_hwmod: l4_ls: cannot be enabled for reset (3)
> [0.124342] omap_hwmod: l4_hs: _wait_target_ready failed: -16
> [0.124352] omap_hwmod: l4_hs: cannot be enabled for reset (3)
> [1.967228] omap_hwmod: emac0: _wait_target_ready failed: -16
>
> Cc: Brian Hutchinson
> Signed-off-by: Neil Armstrong
Thanks for checking the TI tree also in addition to the docs,
applying this one into omap-for-v4.4/fixes.
Tony
> ---
> arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> index b1288f5..6256052 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
> @@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = {
> .name = "l4_ls",
> .clkdm_name = "alwon_l3s_clkdm",
> .class = &l4_hwmod_class,
> + .flags = HWMOD_NO_IDLEST,
> };
>
> /*
> @@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = {
> .name = "l4_hs",
> .clkdm_name = "alwon_l3_med_clkdm",
> .class = &l4_hwmod_class,
> + .flags = HWMOD_NO_IDLEST,
> };
>
> /* L3 slow -> L4 ls peripheral interface running at 125MHz */
> @@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = {
> .name = "emac0",
> .clkdm_name = "alwon_ethernet_clkdm",
> .class = &dm816x_emac_hwmod_class,
> + .flags = HWMOD_NO_IDLEST,
> };
>
> static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = {
> --
> 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 RESEND] ARM: OMAP2+: PM: Denote the cpuidle tracepoints as _rcuidle()
* Jisheng Zhang [151116 02:13]: > The cpuidle tracepoints are called within a rcu_idle_exit() section, and > must be denoted with the _rcuidle() version of the tracepoint. > > Signed-off-by: Jisheng Zhang > Acked-by: Kevin Hilman Sorry I have this in my omap-for-v4.4/fixes but have not sent out pull request yet. Hoping to send it today or on Friday. Regards, Tony > --- > arch/arm/mach-omap2/pm34xx.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c > index 87b98bf9..2dbd378 100644 > --- a/arch/arm/mach-omap2/pm34xx.c > +++ b/arch/arm/mach-omap2/pm34xx.c > @@ -301,11 +301,11 @@ static void omap3_pm_idle(void) > if (omap_irq_pending()) > return; > > - trace_cpu_idle(1, smp_processor_id()); > + trace_cpu_idle_rcuidle(1, smp_processor_id()); > > omap_sram_idle(); > > - trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id()); > + trace_cpu_idle_rcuidle(PWR_EVENT_EXIT, smp_processor_id()); > } > > #ifdef CONFIG_SUSPEND > -- > 2.6.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 2/2] arm: boot: beaglex15: pass correct interrupt
* Chanwoo Choi [151120 08:56]:
> Hi,
>
> On Sat, Nov 21, 2015 at 1:42 AM, Chanwoo Choi wrote:
> > Hi,
> >
> > On 2015. 11. 20. 오후 2:39, Chanwoo Choi wrote:
> >> Hi,
> >>
> >> On 2015년 11월 13일 02:53, Felipe Balbi wrote:
> >>> According to latest schematics [1], GPIO_1/VBUSDET
> >>> on TPS659038 is tied to AM57x GPIO4_21. We can use
> >>> that as a VBUS interrupt, instead of relying on
> >>> PMIC's VBUS interrupts which don't seem to be firing
> >>> on x15 at all.
> >>>
> >>> A follow up patch will add support for using this
> >>> GPIO-based interrupt mechanism for notifying about
> >>> VBUS.
> >>>
> >>> [1]
> >>> https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf
> >>>
> >>> Signed-off-by: Felipe Balbi
> >>> ---
> >>> arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >>> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >>> index 6f3a1a7ec5f9..5e47162f7883 100644
> >>> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >>> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> >>> @@ -560,6 +560,7 @@
> >>> extcon_usb2: tps659038_usb {
> >>> compatible = "ti,palmas-usb-vid";
> >>> ti,enable-vbus-detection;
> >>> +interrupts-extended = <&gpio4 21
> >>> IRQ_TYPE_EDGE_RISING>;
> >
> > vbus-gpio = <&gpio4 21>;
>
> I'm sorry. I'm sending the missing email without writing completion.
>
> I agree the Felipe's opinion. Just I think that we can use the
> following property
> instead of 'interrupt-extended'. Because I think 'vbus-gpio' is more
> readability than before. The following property mean the attribute of
> GPIO pin as VBUS.
> - vbus-gpio = <&gpio4 21>;
Hmm OK not applying the first two patches yet then as it seems changes
are needed. Felipe can you please repost the missing ones after you guys
have figured out which dts changes are needed?
Regards,
Tony
--
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] ARM: OMAP4+: SMP: use lockless clkdm/pwrdm api in omap4_boot_secondary
* Grygorii Strashko [151116 09:39]:
> OMAP CPU hotplug uses cpu1's clocks and power domains for CPU1 wake up
> from low power states (or turn on CPU1). This part of code is also
> part of system suspend (disable_nonboot_cpus()).
> >From other side, cpu1's clocks and power domains are used by CPUIdle. All
> >above
> functionality is mutually exclusive and, therefore, lockless clkdm/pwrdm api
> can be used in omap4_boot_secondary().
>
> This fixes below back-trace on -RT which is triggered by
> pwrdm_lock/unlock():
>
> BUG: sleeping function called from invalid context at
> kernel/locking/rtmutex.c:917
> in_atomic(): 1, irqs_disabled(): 0, pid: 118, name: sh
> 9 locks held by sh/118:
> #0: (sb_writers#4){.+.+.+}, at: [] vfs_write+0x13c/0x164
> #1: (&of->mutex){+.+.+.}, at: [] kernfs_fop_write+0x48/0x19c
> #2: (s_active#24){.+.+.+}, at: [] kernfs_fop_write+0x50/0x19c
> #3: (device_hotplug_lock){+.+.+.}, at: []
> lock_device_hotplug_sysfs+0xc/0x4c
> #4: (&dev->mutex){..}, at: [] device_online+0x14/0x88
> #5: (cpu_add_remove_lock){+.+.+.}, at: [] cpu_up+0x50/0x1a0
> #6: (cpu_hotplug.lock){++}, at: [] cpu_hotplug_begin+0x0/0xc4
> #7: (cpu_hotplug.lock#2){+.+.+.}, at: []
> cpu_hotplug_begin+0x78/0xc4
> #8: (boot_lock){+.+...}, at: [] omap4_boot_secondary+0x1c/0x178
> Preemption disabled at:[< (null)>] (null)
>
> CPU: 0 PID: 118 Comm: sh Not tainted 4.1.12-rt11-01998-gb4a62c3-dirty #137
> Hardware name: Generic DRA74X (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x80/0x94)
> [] (dump_stack) from [] (rt_spin_lock+0x24/0x54)
> [] (rt_spin_lock) from [] (clkdm_wakeup+0x10/0x2c)
> [] (clkdm_wakeup) from []
> (omap4_boot_secondary+0x88/0x178)
> [] (omap4_boot_secondary) from [] (__cpu_up+0xc4/0x164)
> [] (__cpu_up) from [] (cpu_up+0x15c/0x1a0)
> [] (cpu_up) from [] (device_online+0x64/0x88)
> [] (device_online) from [] (online_store+0x68/0x74)
> [] (online_store) from [] (kernfs_fop_write+0xb8/0x19c)
> [] (kernfs_fop_write) from [] (__vfs_write+0x20/0xd8)
> [] (__vfs_write) from [] (vfs_write+0x90/0x164)
> [] (vfs_write) from [] (SyS_write+0x44/0x9c)
> [] (SyS_write) from [] (ret_fast_syscall+0x0/0x54)
> CPU1: smp_ops.cpu_die() returned, trying to resuscitate
>
> Cc: Tero Kristo
> Signed-off-by: Grygorii Strashko
Applying into omap-for-v4.4/fixes thanks.
Tony
> ---
> arch/arm/mach-omap2/omap-smp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 5305ec7..79e1f87 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -143,9 +143,9 @@ static int omap4_boot_secondary(unsigned int cpu, struct
> task_struct *idle)
>* Ensure that CPU power state is set to ON to avoid CPU
>* powerdomain transition on wfi
>*/
> - clkdm_wakeup(cpu1_clkdm);
> - omap_set_pwrdm_state(cpu1_pwrdm, PWRDM_POWER_ON);
> - clkdm_allow_idle(cpu1_clkdm);
> + clkdm_wakeup_nolock(cpu1_clkdm);
> + pwrdm_set_next_pwrst(cpu1_pwrdm, PWRDM_POWER_ON);
> + clkdm_allow_idle_nolock(cpu1_clkdm);
>
> if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)) {
> while (gic_dist_disabled()) {
> --
> 2.6.3
>
--
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: power states transitions
On Wed, Nov 25, 2015 at 8:50 PM, Tony Lindgren wrote:
> * Ran Shalit [151122 07:59]:
>> Hello,
>>
>> I have stranhe behaviour in which even when there is no activity in
>> serial port, the retention counter is keep incremented all these time,
>> as if the cpu gets in and out of retention periodically.
>> I would expect the cpu to get into retention mode, when there is no
>> activity and stay in that state.
>> What can cause such behaviour ? Is it because some background process ?
>
> Sounds like your device is hitting deper idle states during idle. If
> you want to disable that, set the UART autosuspend_delay_ms to -1:
>
> #/bin/bash
> uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
> for uart in $uarts; do
> echo -1 > $uart/autosuspend_delay_ms 2>&1
> done
>
> The above will keep the UARTs active blocking any deeper idle
> states. I believe the value has to be -1 instead of 0 to disable
> autoidle.. but please verify yourself.
>
>> My original problem is that the ethernet performance is very low with
>> small windows. I thought that I can control this value by changing
>> sleep_latency parameter in
>> the following array. Yet, it did not help me. I don't know why.
>
> Maybe test if the above script helps with the Ethernet too. If the
> Ethernet controller is on GPMC, it's not blocking deeper idle states
> automatically in hardware. Adding DMA support to the Ethernet driver
> would be a good way to block deeper idle states automatically by
> the Ethernet hardware.
>
Hi Tony,
We actually want the deeper state, but not in the price of performance...
So I thought of these possibilities:
1. configure the sleep state to check activity for a longer time than
micro seconds (several seconds). If there is non activity in that long
period, only than will move to retention. I am not sure if there is
such configuration parameter . Maybe one of the following parameters
can be configured for this option ?
46 struct cpuidle_params {
47 u32 exit_latency; /* exit_latency = sleep + wake-up
latencies */
48 u32 target_residency;
49 u8 valid; /* validates the C-state */
50 };
2. Another option can be to write a kernel module which check if there
is ethernet activity for X seconds, if there is none - it will enable
power management , otherwise - it will disable the power management.
These maybe can solve the ethernet issue, but I still not sure why
there is constantly incrementation in the retention state, as if it
enter and leave the state all periodically. Is it becuase some
task/thread/process in the system (I guess it can be a kernel process
actually) ?
Regards,
Ran
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: > * Pali Rohár [151123 06:46]: > > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote: > > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote: > > > > Adding devicetree list. > > > > > > > > Thread starts at > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html > > > > > > > > On 11/5/2015 8:17 AM, Tony Lindgren wrote: > > > > > * Pali Rohár [151105 03:41]: > > > > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: > > > > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: > > > > * Pali Rohár [151012 13:29]: > > > > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > > > > >> > > > > >> Pali, any news on posting an updated series with the comments > > > > >> addressed in this thread? It seems that we all pretty much agree > > > > >> what needs to be done. > > > > > > > > I'm not real happy with the concept of patches 4 and 5 in this series. > > > > My concern is that those two patches are using the FDT as a transport > > > > mechanism for a binary blob (the atags object). > > > > > > Umm. Ok. Do you have alternative proposal that works for everyone? > > > > > > I mean. This discussion was going for quite a long time, and it would > > > be nice to have some solution... patch proposal... something. > > > Pavel > > > > Yes, discussion is going for a long time! So should I spend time for > > adding documentation to my solution (this is last one thing which is > > missing)? Or my solution is wrong and somebody else will propose new? > > I do not want to spend time on something which will be rejected and > > discarded. > > At least I don't have better solutions in mind. I would be happier if we could restrict this as much as possible to the boards that need it, as an opt-in. That way it doesn't become an ABI for people that don't already rely in this information. How about adding a check the code adds the linux,atags property to do it only for a whitelist of board numbers? Arnd -- 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] PCI: designware: bail out if host_init failed
Hi Jisheng,
On Thu, Nov 12, 2015 at 09:48:45PM +0800, Jisheng Zhang wrote:
> There's no reason to continue the initialization such as configure
> register, scan root bus etc. if customized host_init() failed. This
> patch tries to check the host_init result, bail out if failed.
This patch changes the (*host_init) return type and adds "return 0" to
the host_init() implementations of ten different drivers, all to
support a possible error in one driver.
Is there any way to detect and handle the error in
ls1021_pcie_host_init() earlier, maybe by doing the syscon_regmap
lookup in ls_pcie_probe() instead of in the host_init() function?
That would be even better because you wouldn't have to touch any of
the other drivers, and you'd detect the error even earlier, before
we've done any of the designware setup.
Bjorn
> Signed-off-by: Jisheng Zhang
> ---
> drivers/pci/host/pci-dra7xx.c | 4 +++-
> drivers/pci/host/pci-exynos.c | 4 +++-
> drivers/pci/host/pci-imx6.c| 4 +++-
> drivers/pci/host/pci-keystone.c| 4 +++-
> drivers/pci/host/pci-layerscape.c | 25 -
> drivers/pci/host/pcie-designware.c | 7 +--
> drivers/pci/host/pcie-designware.h | 2 +-
> drivers/pci/host/pcie-spear13xx.c | 4 +++-
> 8 files changed, 37 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> index 8c36880..b3160a1 100644
> --- a/drivers/pci/host/pci-dra7xx.c
> +++ b/drivers/pci/host/pci-dra7xx.c
> @@ -149,7 +149,7 @@ static void dra7xx_pcie_enable_interrupts(struct
> pcie_port *pp)
> LEG_EP_INTERRUPTS);
> }
>
> -static void dra7xx_pcie_host_init(struct pcie_port *pp)
> +static int dra7xx_pcie_host_init(struct pcie_port *pp)
> {
> dw_pcie_setup_rc(pp);
>
> @@ -162,6 +162,8 @@ static void dra7xx_pcie_host_init(struct pcie_port *pp)
> if (IS_ENABLED(CONFIG_PCI_MSI))
> dw_pcie_msi_init(pp);
> dra7xx_pcie_enable_interrupts(pp);
> +
> + return 0;
> }
>
> static struct pcie_host_ops dra7xx_pcie_host_ops = {
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index 01095e1..57f370b 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -481,10 +481,12 @@ static int exynos_pcie_link_up(struct pcie_port *pp)
> return 0;
> }
>
> -static void exynos_pcie_host_init(struct pcie_port *pp)
> +static int exynos_pcie_host_init(struct pcie_port *pp)
> {
> exynos_pcie_establish_link(pp);
> exynos_pcie_enable_interrupts(pp);
> +
> + return 0;
> }
>
> static struct pcie_host_ops exynos_pcie_host_ops = {
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
> index 22e8224..9a46680 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -425,7 +425,7 @@ static int imx6_pcie_establish_link(struct pcie_port *pp)
> return 0;
> }
>
> -static void imx6_pcie_host_init(struct pcie_port *pp)
> +static int imx6_pcie_host_init(struct pcie_port *pp)
> {
> imx6_pcie_assert_core_reset(pp);
>
> @@ -439,6 +439,8 @@ static void imx6_pcie_host_init(struct pcie_port *pp)
>
> if (IS_ENABLED(CONFIG_PCI_MSI))
> dw_pcie_msi_init(pp);
> +
> + return 0;
> }
>
> static void imx6_pcie_reset_phy(struct pcie_port *pp)
> diff --git a/drivers/pci/host/pci-keystone.c b/drivers/pci/host/pci-keystone.c
> index 0aa81bd..2604571 100644
> --- a/drivers/pci/host/pci-keystone.c
> +++ b/drivers/pci/host/pci-keystone.c
> @@ -250,7 +250,7 @@ static int keystone_pcie_fault(unsigned long addr,
> unsigned int fsr,
> return 0;
> }
>
> -static void __init ks_pcie_host_init(struct pcie_port *pp)
> +static int __init ks_pcie_host_init(struct pcie_port *pp)
> {
> struct keystone_pcie *ks_pcie = to_keystone_pcie(pp);
> u32 val;
> @@ -277,6 +277,8 @@ static void __init ks_pcie_host_init(struct pcie_port *pp)
>*/
> hook_fault_code(17, keystone_pcie_fault, SIGBUS, 0,
> "Asynchronous external abort");
> +
> + return 0;
> }
>
> static struct pcie_host_ops keystone_pcie_host_ops = {
> diff --git a/drivers/pci/host/pci-layerscape.c
> b/drivers/pci/host/pci-layerscape.c
> index 3923bed..a6e9070 100644
> --- a/drivers/pci/host/pci-layerscape.c
> +++ b/drivers/pci/host/pci-layerscape.c
> @@ -94,8 +94,9 @@ static int ls1021_pcie_link_up(struct pcie_port *pp)
> return 1;
> }
>
> -static void ls1021_pcie_host_init(struct pcie_port *pp)
> +static int ls1021_pcie_host_init(struct pcie_port *pp)
> {
> + int ret;
> struct ls_pcie *pcie = to_ls_pcie(pp);
> u32 val, index[2];
>
> @@ -103,15 +104,14 @@ static void ls1021_pcie_host_init(struct pcie_port *pp)
>"fsl,pcie-scfg");
> if (IS_ERR(pcie->scfg)) {
> dev_err(pp->dev, "No syscfg phandle specified\n");
> - pcie->scfg
Re: [PATCH 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support
On Wed, Nov 25, 2015 at 08:39:33AM +0200, Dmitry Lifshitz wrote:
> Add support for CompuLab CM-SOM-AM57X board.
>
> CL-SOM-AM57x is a miniature System-on-Module (SoM) based on
> TI Sitara AM57x ARM Cortex-A15 System-on-Chip family.
>
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
>
> Add basic DT support for standalone module (without a carrier board):
>
> * Memory configuration
> * Heartbeat led
> * I2C1 bus
> * PMIC
> * SATA
>
> Signed-off-by: Dmitry Lifshitz
> Acked-by: Igor Grinberg
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/am57xx-cl-som-am57x.dts | 259
> +
> 3 files changed, 264 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/am57xx-cl-som-am57x.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index da84372..dd53c90 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -156,6 +156,9 @@ Boards:
> - AM437x SK EVM: AM437x StarterKit Evaluation Module
>compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
>
> +- AM57XX CL-SOM-AM57x
> + compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742",
> "ti,dra74", "ti,dra7"
> +
> - DRA742 EVM: Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 5492a24..803a020 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -477,8 +477,9 @@ dtb-$(CONFIG_SOC_OMAP5) += \
> omap5-sbc-t54.dtb \
> omap5-uevm.dtb
> dtb-$(CONFIG_SOC_DRA7XX) += \
> - dra7-evm.dtb \
> am57xx-beagle-x15.dtb \
> + am57xx-cl-som-am57x.dtb \
> + dra7-evm.dtb \
> dra72-evm.dtb
> dtb-$(CONFIG_ARCH_ORION5X) += \
> orion5x-lacie-d2-network.dtb \
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> new file mode 100644
> index 000..b11d7da
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> @@ -0,0 +1,259 @@
> +/*
> + * Support for CompuLab CL-SOM-AM57x System-on-Module
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "dra74x.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x";
> + compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742",
> "ti,dra74", "ti,dra7";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB - minimal
> configuration */
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_pins_default>;
> +
> + led@0 {
> + label = "cl-som-am57x:green";
> + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> + };
> +};
> +
> +&dra7_pmx_core {
> + leds_pins_default: leds_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)
> /* gpmc_a15.gpio2_5 */
> + >;
> + };
> +
> + i2c1_pins_default: i2c1_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0)
> /* i2c1_sda.sda */
> + DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0)
> /* i2c1_scl.scl */
> + >;
> + };
> +
> + tps659038_pins_default: tps659038_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP |
> MUX_MODE14) /* wakeup0.gpio1_0 */
> + >;
> + };
> +};
> +
> +&i2c1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_default>;
> + clock-frequency = <40>;
> +
> + tps659038: tps659038@58 {
> + compatible = "ti,tps659038";
> + reg = <0x58>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&tps659038_pins_default>;
> +
> + #interrupt-cells = <2>;
> + interrupt-controller;
> +
> + ti,system-power-controller;
> +
> + tps659038_pmic
Re: [PATCH 11/18] ARM: am57xx: sbc-am57x: dts: add basic board support
On Wed, Nov 25, 2015 at 08:39:43AM +0200, Dmitry Lifshitz wrote:
> SBC-AM57x is a single board computer designed for industrial and
> embedded applications. It is based on the Texas Instruments Sitara AM57x
> system-on-chip family. SBC-AM57x is implemented with the CL-SOM-AM57x
> computer-on-module providing most of the functions, and SB-SOM-AM57x
> carrier board providing additional peripheral functions and connectors.
>
> https://www.compulab.co.il/products/sbcs/sbc-am57x-ti-am5728-am5718-single-board-computer/
>
> https://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/
>
> Add basic board support, including UART3, used as a serial console.
>
> Signed-off-by: Dmitry Lifshitz
> Acked-by: Igor Grinberg
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/arm/omap/omap.txt | 3 ++
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am57xx-sbc-am57x.dts | 36
> ++
> 3 files changed, 40 insertions(+)
> create mode 100644 arch/arm/boot/dts/am57xx-sbc-am57x.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index dd53c90..42cdad1 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -159,6 +159,9 @@ Boards:
> - AM57XX CL-SOM-AM57x
>compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742",
> "ti,dra74", "ti,dra7"
>
> +- AM57XX SBC-AM57x
> + compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728",
> "ti,dra742", "ti,dra74", "ti,dra7"
> +
> - DRA742 EVM: Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 803a020..4c73ab9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -479,6 +479,7 @@ dtb-$(CONFIG_SOC_OMAP5) += \
> dtb-$(CONFIG_SOC_DRA7XX) += \
> am57xx-beagle-x15.dtb \
> am57xx-cl-som-am57x.dtb \
> + am57xx-sbc-am57x.dtb \
> dra7-evm.dtb \
> dra72-evm.dtb
> dtb-$(CONFIG_ARCH_ORION5X) += \
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> new file mode 100644
> index 000..804ad72
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -0,0 +1,36 @@
> +/*
> + * Support for CompuLab SBC-AM57x single board computer
> + *
> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + * Author: Dmitry Lifshitz
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + */
> +
> +#include "am57xx-cl-som-am57x.dts"
> +#include "compulab-sb-som.dtsi"
> +
> +/ {
> + model = "CompuLab CL-SOM-AM57x on SB-SOM-AM57x";
> + compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x",
> "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7";
> +};
> +
> +&dra7_pmx_core {
> + uart3_pins_default: uart3_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_SLEW | MUX_MODE2)
> /* uart2_ctsn.uart3_rxd */
> + DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_SLEW | MUX_MODE1)
> /* uart2_rtsn.uart3_txd */
> + >;
> + };
> +};
> +
> +&uart3 {
> + status = "okay";
> + interrupts-extended = <&crossbar_mpu GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> + <&dra7_pmx_core 0x3f8>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins_default>;
> +};
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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] ARM: omap2plus_defconfig: enable REGULATOR_FIXED_VOLTAGE
On 11/25/2015 08:25 PM, Tony Lindgren wrote: > * Grygorii Strashko [151105 08:45]: >> Enable REGULATOR_FIXED_VOLTAGE otherwise system can't boot from >> SD-card when kernel is buit with CONFIG_SOC_DRA7XX=y only. >> >> It's also required for almost all other TI SoC's platforms. > > This is already enabled by default when you do make omap2plus_defconfig? Yes. But only because it's hard-coded for MACH_OMAP3_PANDORA :( config MACH_OMAP3_PANDORA bool "OMAP3 Pandora" depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB select REGULATOR_FIXED_VOLTAGE if REGULATOR But I can't boot from SD-card if I'm trying SoC specific build, like only SOC_DRA7XX=y above. -- regards, -grygorii -- 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] ARM: omap2plus_defconfig: enable REGULATOR_FIXED_VOLTAGE
* Grygorii Strashko [151125 12:26]: > On 11/25/2015 08:25 PM, Tony Lindgren wrote: > > * Grygorii Strashko [151105 08:45]: > >> Enable REGULATOR_FIXED_VOLTAGE otherwise system can't boot from > >> SD-card when kernel is buit with CONFIG_SOC_DRA7XX=y only. > >> > >> It's also required for almost all other TI SoC's platforms. > > > > This is already enabled by default when you do make omap2plus_defconfig? > > Yes. But only because it's hard-coded for MACH_OMAP3_PANDORA :( > config MACH_OMAP3_PANDORA > bool "OMAP3 Pandora" > depends on ARCH_OMAP3 > default y > select OMAP_PACKAGE_CBB > select REGULATOR_FIXED_VOLTAGE if REGULATOR > > But I can't boot from SD-card if I'm trying SoC specific build, > like only SOC_DRA7XX=y above. Well let's move to under config ARCH_OMAP2PLUS in the Kconfig? Otherwise if somebody does make savedefconfig it will disappear again from omap2plus_defconfig. Regards, Tony -- 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
* Arnd Bergmann [151125 11:50]: > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: > > * Pali Rohár [151123 06:46]: > > > On Sunday 22 November 2015 07:51:46 Pavel Machek wrote: > > > > On Wed 2015-11-11 17:10:46, Frank Rowand wrote: > > > > > Adding devicetree list. > > > > > > > > > > Thread starts at > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html > > > > > > > > > > On 11/5/2015 8:17 AM, Tony Lindgren wrote: > > > > > > * Pali Rohár [151105 03:41]: > > > > > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: > > > > > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: > > > > > * Pali Rohár [151012 13:29]: > > > > > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > > > > > >> > > > > > >> Pali, any news on posting an updated series with the comments > > > > > >> addressed in this thread? It seems that we all pretty much > > > > > >> agree > > > > > >> what needs to be done. > > > > > > > > > > I'm not real happy with the concept of patches 4 and 5 in this series. > > > > > My concern is that those two patches are using the FDT as a transport > > > > > mechanism for a binary blob (the atags object). > > > > > > > > Umm. Ok. Do you have alternative proposal that works for everyone? > > > > > > > > I mean. This discussion was going for quite a long time, and it would > > > > be nice to have some solution... patch proposal... something. > > > > > > > > Pavel > > > > > > Yes, discussion is going for a long time! So should I spend time for > > > adding documentation to my solution (this is last one thing which is > > > missing)? Or my solution is wrong and somebody else will propose new? > > > I do not want to spend time on something which will be rejected and > > > discarded. > > > > At least I don't have better solutions in mind. > > I would be happier if we could restrict this as much as possible to the > boards that need it, as an opt-in. That way it doesn't become an ABI > for people that don't already rely in this information. How about > adding a check the code adds the linux,atags property to do it > only for a whitelist of board numbers? Or populate /proc/atags only for the ones that need it from machine specific init_early? Regards, Tony -- 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: power states transitions
* Ran Shalit [151125 11:49]:
> On Wed, Nov 25, 2015 at 8:50 PM, Tony Lindgren wrote:
>
> We actually want the deeper state, but not in the price of performance...
> So I thought of these possibilities:
> 1. configure the sleep state to check activity for a longer time than
> micro seconds (several seconds). If there is non activity in that long
> period, only than will move to retention. I am not sure if there is
> such configuration parameter . Maybe one of the following parameters
> can be configured for this option ?
>
> 46 struct cpuidle_params {
> 47 u32 exit_latency; /* exit_latency = sleep + wake-up
> latencies */
> 48 u32 target_residency;
> 49 u8 valid; /* validates the C-state */
> 50 };
>
> 2. Another option can be to write a kernel module which check if there
> is ethernet activity for X seconds, if there is none - it will enable
> power management , otherwise - it will disable the power management.
It really should be implemented with the standard pm_runtime calls in the
Ethernet driver. Maybe you can clk_get some parent clock from the Ethernet
driver that will block the idle state?
> These maybe can solve the ethernet issue, but I still not sure why
> there is constantly incrementation in the retention state, as if it
> enter and leave the state all periodically. Is it becuase some
> task/thread/process in the system (I guess it can be a kernel process
> actually) ?
I think what you're seeing is the kernel idle code incrementing it
every time the SoC hits idle.
Regards,
Tony
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote: > * Arnd Bergmann [151125 11:50]: > > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: > > > At least I don't have better solutions in mind. > > > > I would be happier if we could restrict this as much as possible to the > > boards that need it, as an opt-in. That way it doesn't become an ABI > > for people that don't already rely in this information. How about > > adding a check the code adds the linux,atags property to do it > > only for a whitelist of board numbers? > > Or populate /proc/atags only for the ones that need it from machine > specific init_early? That would also address my main concern about /proc/atags, but still leave the atags in /proc/device-tree/chosen/linux,atags, and it would be bad if someone who currently uses /proc/atags changes their code to use the other file instead of finding a proper solution. Arnd -- 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 01/18] ARM: am57xx: cl-som-am57x: dts: add basic module support
On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
[...]
> diff --git a/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
> new file mode 100644
> index 000..b11d7da
> --- /dev/null
> +++ b/arch/arm/boot/dts/am57xx-cl-som-am57x.dts
[...]
> +/ {
> + model = "CompuLab CL-SOM-AM57x";
> + compatible = "compulab,cl-som-am57x", "ti,am5728", "ti,dra742",
> "ti,dra74", "ti,dra7";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x2000>; /* 512 MB - minimal
> configuration */
I think if you like to enable LPAE, the format might look a little
different..
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_pins_default>;
> +
> + led@0 {
> + label = "cl-som-am57x:green";
> + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> + };
> +};
> +
> +&dra7_pmx_core {
> + leds_pins_default: leds_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x347c, PIN_OUTPUT | MUX_MODE14)
> /* gpmc_a15.gpio2_5 */
> + >;
> + };
> +
> + i2c1_pins_default: i2c1_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT_PULLUP | MUX_MODE0)
> /* i2c1_sda.sda */
> + DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT_PULLUP | MUX_MODE0)
> /* i2c1_scl.scl */
> + >;
> + };
> +
> + tps659038_pins_default: tps659038_pins_default {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3818, PIN_INPUT_PULLUP |
> MUX_MODE14) /* wakeup0.gpio1_0 */
> + >;
> + };
Generic comment: As per requirements of the SoC -> all pinctrl must be
done in bootloader. this was a recommendation that came in too late
for TI platforms that got introduced in upstream, but that cleanup
should eventually take place as well.
> +};
> +
> +&i2c1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins_default>;
> + clock-frequency = <40>;
> +
> + tps659038: tps659038@58 {
> + compatible = "ti,tps659038";
> + reg = <0x58>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
Also See: https://patchwork.kernel.org/patch/7596541/ ->
Documentation/devicetree/bindings/i2c/i2c.txt -> since you seem to
have a PMIC with power button, you might be able to get wakeup source
also there.
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&tps659038_pins_default>;
> +
> + #interrupt-cells = <2>;
> + interrupt-controller;
> +
> + ti,system-power-controller;
Assuming powerhold signal and BOOT0,1 is proper here, else poweroff
will never work.
> +
> + tps659038_pmic {
> + compatible = "ti,tps659038-pmic";
> +
> + regulators {
> + smps12_reg: smps12 {
> + /* VDD_MPU */
> + regulator-name = "smps12";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <125>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps3_reg: smps3 {
> + /* VDD_DDR */
> + regulator-name = "smps3";
> + regulator-min-microvolt = <150>;
> + regulator-max-microvolt = <150>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps45_reg: smps45 {
> + /* VDD_DSPEVE */
> + regulator-name = "smps45";
> + regulator-min-microvolt = < 85>;
> + regulator-max-microvolt = <116>;
1.25v if you want to support OPP_HIGH. as per latest data sheet.
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps6_reg: smps6 {
> + /* VDD_GPU */
> + regulator-name = "smps6";
> + regulator-min-microvolt = < 85>;
> +
Re: [PATCH 15/18] ARM: am57xx: sbc-am57x: dts: add GPIO extender support
On 11/25/2015 12:39 AM, Dmitry Lifshitz wrote:
> Add PCA9555 GPIO extender support (over I2C5 bus).
I think you meant to say "GPIO expander" in commit message and
$subject perhaps?
>
> Signed-off-by: Dmitry Lifshitz
> Acked-by: Igor Grinberg
> ---
> arch/arm/boot/dts/am57xx-sbc-am57x.dts | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> index 7b65efb..8b7c0b5 100644
> --- a/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> +++ b/arch/arm/boot/dts/am57xx-sbc-am57x.dts
> @@ -90,4 +90,11 @@
> reg = <0x50>;
> pagesize = <16>;
> };
> +
> + pca9555: pca9555@20 {
> + compatible = "nxp,pca9555";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> };
>
--
Regards,
Nishanth Menon
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 22:29:53 Arnd Bergmann wrote: > On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote: > > * Arnd Bergmann [151125 11:50]: > > > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: > > > > At least I don't have better solutions in mind. > > > > > > I would be happier if we could restrict this as much as possible > > > to the boards that need it, as an opt-in. That way it doesn't > > > become an ABI for people that don't already rely in this > > > information. How about adding a check the code adds the > > > linux,atags property to do it only for a whitelist of board > > > numbers? > > > > Or populate /proc/atags only for the ones that need it from machine > > specific init_early? > > That would also address my main concern about /proc/atags, but still > leave the atags in /proc/device-tree/chosen/linux,atags, and it would > be bad if someone who currently uses /proc/atags changes their code > to use the other file instead of finding a proper solution. > > Arnd Arnd, my question about proper solution reminds... Proprietary bootloader which cannot be replaced (e.g. it is signed or do unknown magic) provides information to booted kernel via custom specific ATAGs fields. How userspace could properly read those custom information from bootloader? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote: > > Arnd, my question about proper solution reminds... Proprietary > bootloader which cannot be replaced (e.g. it is signed or do unknown > magic) provides information to booted kernel via custom specific ATAGs > fields. How userspace could properly read those custom information from > bootloader? The typical solution for nonstandard bootloaders is to have a boot wrapper like the one from https://github.com/zonque/pxa-impedance-matcher that translates whatever information we have at the bootloader level into DT properties. As I understand, the reason we are not doing that here is that we also have proprietary user space that we can't fix to look in a different place, i.e. the interface is between the bootloader and some user binary, not bootloader to kernel. Arnd -- 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 22:51:00 Arnd Bergmann wrote: > On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote: > > Arnd, my question about proper solution reminds... Proprietary > > bootloader which cannot be replaced (e.g. it is signed or do > > unknown magic) provides information to booted kernel via custom > > specific ATAGs fields. How userspace could properly read those > > custom information from bootloader? > > The typical solution for nonstandard bootloaders is to have a boot > wrapper like the one from > https://github.com/zonque/pxa-impedance-matcher that translates > whatever information we have at the bootloader level into DT > properties. > Ok. So there is no better solution. With some hacks we can use U-Boot as 3rd stage bootloader. But this is not useful for debugging or developing... Ideal "wrapper" solution would be to compile wrapper and linux zImage and then glue them together to one binary. Something like internal linux uncompress code which translate atags to dt. > As I understand, the reason we are not doing that here is that we > also have proprietary user space that we can't fix to look in a > different place, i.e. the interface is between the bootloader and > some user binary, not bootloader to kernel. > Yes, proprietary/closed applications are problems which we cannot fix (without rewriting them). New applications could use new "proper" interface. But without that interface we cannot do that. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[GIT PULL] omap fixes against v4.4-rc2
The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4: Linux 4.4-rc2 (2015-11-22 16:45:59 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.4/fixes-rc2 for you to fetch changes up to 918af9f941af9995fcaa7ef1eb67c433a492e2b3: ARM: OMAP4+: SMP: use lockless clkdm/pwrdm api in omap4_boot_secondary (2015-11-25 11:03:20 -0800) Fixes for omaps for v4.4-rc cycle: - A series of audio changes for dra7 that missed the merge window but turned out to be necessary to fix a boot time imprecise external abort error and to getaudio working - Fix l4 related boot time errors for dm81xx - Use lockless cldm/pwrdm api in omap4_boot_secondary - Remove t410 custom abort handler that is no longer needed and may hide other critical errors - Mark cpuidle tracepoints as _rcuidle - Fix module alias for omap-ocp2scp Axel Lin (1): bus: omap-ocp2scp: Fix module alias Grygorii Strashko (1): ARM: OMAP4+: SMP: use lockless clkdm/pwrdm api in omap4_boot_secondary Jisheng Zhang (1): ARM: OMAP2+: PM: Denote the cpuidle tracepoints as _rcuidle() Lucas Stach (1): ARM: OMAP2+: remove custom abort handler for t410 Neil Armstrong (1): arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data Peter Ujfalusi (3): ARM: dts: dra7: Fix McASP3 node regarding to clocks ARM: OMAP2+: hwmod: Add hwmod flag for HWMOD_OPT_CLKS_NEEDED ARM: OMAP: DRA7: hwmod: Add data for McASP3 Tony Lindgren (2): Merge branch 'x15-audio-fixes' into omap-for-v4.4/fixes Merge branch '81xx' into omap-for-v4.4/fixes arch/arm/boot/dts/dra7.dtsi| 4 +- arch/arm/mach-omap2/omap-smp.c | 6 +-- arch/arm/mach-omap2/omap_hwmod.c | 66 -- arch/arm/mach-omap2/omap_hwmod.h | 3 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 56 + arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 ++ arch/arm/mach-omap2/pdata-quirks.c | 29 - arch/arm/mach-omap2/pm34xx.c | 4 +- drivers/bus/omap-ocp2scp.c | 2 +- 9 files changed, 106 insertions(+), 67 deletions(-) -- 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 1/6] ARM: OMAP2+: dts: cm-t335: add initial support
On Tue, Nov 24, 2015 at 04:02:08PM +0200, Uri Mashiach wrote:
> From: Ilya Ledvich
>
> Add basic support for CompuLab cm-t335 module based on AM335X SoC.
>
> CM-T335 is a tiny computer-on-module (CoM) / system-on-module (SoM)
> The module is built around the Texas Instruments Sitara AM3352/4
> system-on-chip.
>
> The CPU is supplemented with up-to 512MB DDR3 and up-to 1GB of on-board
> NAND storage, WiFi connected to SPI, Bluetooth, Analog audio, Gigabit
> Ethernet, CAN bus.
>
> Current patch adds support:
> UART0 and GPIO LED
>
> Detailed description can be found at the module site:
> http://www.compulab.co.il/products/computer-on-modules/cm-t335/
>
> Signed-off-by: Ilya Ledvich
> [uri.mashi...@compulab.co.il: the default RAM amount reduced to
> 128MB to support also the minimal module configuration]
> Signed-off-by: Uri Mashiach
> Acked-by: Igor Grinberg
> ---
> v1 -> v2: integrate AM33XX_IOPAD macro in pinmux definitions
This macro is exactly the kind we should not be doing in DT files which
are ones that expand to multiple cells. But not really much point in
doing 1 board differently from the rest, so:
Acked-by: Rob Herring
Rob
>
> .../devicetree/bindings/arm/omap/omap.txt | 3 ++
> arch/arm/boot/dts/Makefile | 7 +--
> arch/arm/boot/dts/am335x-cm-t335.dts | 63
> ++
> 3 files changed, 70 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/boot/dts/am335x-cm-t335.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 9f4e513..2154f97 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -138,6 +138,9 @@ Boards:
> - AM335X phyBOARD-WEGA: Single Board Computer dev kit
>compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
>
> +- AM335X CM-T335 : System On Module, built around the Sitara AM3352/4
> + compatible = "compulab,cm-t335", "ti,am33xx"
> +
> - OMAP5 EVM : Evaluation Module
>compatible = "ti,omap5-evm", "ti,omap5"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index bb8fa02..0e011dc 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -446,13 +446,14 @@ dtb-$(CONFIG_SOC_AM33XX) += \
> am335x-base0033.dtb \
> am335x-bone.dtb \
> am335x-boneblack.dtb \
> - am335x-sl50.dtb \
> + am335x-chiliboard.dtb \
> + am335x-cm-t335.dtb \
> am335x-evm.dtb \
> am335x-evmsk.dtb \
> + am335x-lxm.dtb \
> am335x-nano.dtb \
> am335x-pepper.dtb \
> - am335x-lxm.dtb \
> - am335x-chiliboard.dtb \
> + am335x-sl50.dtb \
> am335x-wega-rdk.dtb
> dtb-$(CONFIG_ARCH_OMAP4) += \
> omap4-duovero-parlor.dtb \
> diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts
> b/arch/arm/boot/dts/am335x-cm-t335.dts
> new file mode 100644
> index 000..719658e
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-cm-t335.dts
> @@ -0,0 +1,63 @@
> +/*
> + * am335x-cm-t335.dts - Device Tree file for Compulab CM-T335
> + *
> + * Copyright (C) 2014 - 2015 CompuLab Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include "am33xx.dtsi"
> +
> +/ {
> + model = "CompuLab CM-T335";
> + compatible = "compulab,cm-t335", "ti,am33xx";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x800>; /* 128 MB */
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_led_pins>;
> + led@0 {
> + label = "cm_t335:green";
> + gpios = <&gpio2 0 GPIO_ACTIVE_LOW>; /* gpio2_0 */
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
> +
> +&am33xx_pinmux {
> + pinctrl-names = "default";
> + pinctrl-0 = <>;
> +
> + gpio_led_pins: pinmux_gpio_led_pins {
> + pinctrl-single,pins = <
> + /* gpmc_csn3.gpio2_0 */
> + AM33XX_IOPAD(0x888, PIN_OUTPUT | MUX_MODE7)
> + >;
> + };
> +
> + uart0_pins: pinmux_uart0_pins {
> + pinctrl-single,pins = <
> + /* uart0_rxd.uart0_rxd */
> + AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)
> + /* uart0_txd.uart0_txd */
> + AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
> + >;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins>;
> +
> + status = "okay";
> +};
> +
> --
> 2.5.0
>
--
To unsubscribe from this list: send t
Re: [GIT PULL] omap fixes against v4.4-rc2
On Wednesday 25 November 2015 14:37:04 Tony Lindgren wrote: > Fixes for omaps for v4.4-rc cycle: > > - A series of audio changes for dra7 that missed the merge window but turned > out to be necessary to fix a boot time imprecise external abort error and to > getaudio working > > - Fix l4 related boot time errors for dm81xx > > - Use lockless cldm/pwrdm api in omap4_boot_secondary > > - Remove t410 custom abort handler that is no longer needed and may > hide other critical errors > > - Mark cpuidle tracepoints as _rcuidle > > - Fix module alias for omap-ocp2scp > Merged into fixes, thanks! Arnd -- 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 12/14] ARM: sb-som: dts: introduce SB-SOM baseboard
On Tue, Nov 24, 2015 at 03:19:13PM +0200, Nikita Kiryanov wrote:
> CompuLab SB-SOM baseboard is a carrier board for multiple arm-based SoMs.
> It currently supports (with minor adjustments to assembly) CM-T43, CM-T54,
> and CM-QS600 modules. It is a building block in the SBC-T43 single board
> computer, which consists of cm-t43 on top of sb-som-t43.
>
> Signed-off-by: Nikita Kiryanov
> Cc: Tony Lindgren
> Cc: Igor Grinberg
> Cc: Dmitry Lifshitz
> Cc: Ian Campbell
> ---
> .../devicetree/bindings/arm/compulab-boards.txt| 5 +++
> .../bindings/display/panel/startek,startek-kd050c | 4 +++
.txt please.
> .../devicetree/bindings/vendor-prefixes.txt| 1 +
> arch/arm/boot/dts/compulab-sb-som.dtsi | 42
> ++
> 4 files changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> create mode 100644 arch/arm/boot/dts/compulab-sb-som.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt
> b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> new file mode 100644
> index 000..3e742a5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/compulab-boards.txt
> @@ -0,0 +1,5 @@
> +CompuLab SB-SOM is a multi-module baseboard capable of carrying CM-T43,
> CM-T54,
> +and QS-600 modules with minor modifications to the SB-SOM assembly.
All these modules have compatible strings?
> +
> +Required root node properties:
> +- compatible = should be "compulab,sb-som"
> diff --git
> a/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> new file mode 100644
> index 000..70cd8d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/startek,startek-kd050c
> @@ -0,0 +1,4 @@
> +Startek Electronic Technology Co. KD050C 5.0" WVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "startek,startek-kd050c"
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 55df1d4..409b134 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -218,6 +218,7 @@ sony Sony Corporation
> spansion Spansion Inc.
> sprd Spreadtrum Communications Inc.
> st STMicroelectronics
> +startek Startek
> ste ST-Ericsson
> stericsson ST-Ericsson
> synology Synology, Inc.
> diff --git a/arch/arm/boot/dts/compulab-sb-som.dtsi
> b/arch/arm/boot/dts/compulab-sb-som.dtsi
> new file mode 100644
> index 000..402a143
> --- /dev/null
> +++ b/arch/arm/boot/dts/compulab-sb-som.dtsi
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/ {
> + model = "CompuLab SB-SOM";
> + compatible = "compulab,sb-som";
I would expect this to have a more specific.
> + lcd0: display {
> + compatible = "startek,startek-kd050c", "panel-dpi";
> + label = "lcd";
This isn't documented, nor do I think it is needed.
Rob
--
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 01/14] ARM: am437x: cm-t43: dts: add basic support for sbc-t43
On Tue, Nov 24, 2015 at 03:19:02PM +0200, Nikita Kiryanov wrote:
> Add basic support for SBC-T43: a CM-T43 based single board computer.
> CM-T43 is an AM437x based System-on-Module designed to serve as a building
> block in embedded applications. SBC-T43 is composed of CM-T43 module on
> top of the SB-SOM-T43 baseboard.
> Basic support includes UART, GPIO, and I2C.
>
> Signed-off-by: Nikita Kiryanov
> Cc: Tony Lindgren
> Cc: Igor Grinberg
> Cc: Dmitry Lifshitz
> Cc: Ian Campbell
Some minor nits below, otherwise:
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/arm/omap/omap.txt | 6 ++
> arch/arm/boot/dts/Makefile | 6 +-
> arch/arm/boot/dts/am437x-cm-t43.dts| 90
> ++
> arch/arm/boot/dts/am437x-sbc-t43.dts | 57 ++
> 4 files changed, 157 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/am437x-cm-t43.dts
> create mode 100644 arch/arm/boot/dts/am437x-sbc-t43.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 9f4e513..da84372 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -141,6 +141,12 @@ Boards:
> - OMAP5 EVM : Evaluation Module
>compatible = "ti,omap5-evm", "ti,omap5"
>
> +- AM437x CM-T43
> + compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
> +
> +- AM437x SBC-T43
> + compatible =
> "compulab,am437x-sbc-t43","compulab,am437x-cm-t43","ti,am4372","ti,am43"
^
spaces
> +
> - AM43x EPOS EVM
>compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 30bbc37..dc3b9af 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -478,9 +478,11 @@ dtb-$(CONFIG_ARCH_OMAP4) += \
> omap4-var-stk-om44.dtb
> dtb-$(CONFIG_SOC_AM43XX) += \
> am43x-epos-evm.dtb \
> - am437x-sk-evm.dtb \
> + am437x-cm-t43.dtb \
> + am437x-gp-evm.dtb \
> am437x-idk-evm.dtb \
> - am437x-gp-evm.dtb
> + am437x-sbc-t43.dtb \
> + am437x-sk-evm.dtb
> dtb-$(CONFIG_SOC_OMAP5) += \
> omap5-cm-t54.dtb \
> omap5-igep0050.dtb \
> diff --git a/arch/arm/boot/dts/am437x-cm-t43.dts
> b/arch/arm/boot/dts/am437x-cm-t43.dts
> new file mode 100644
> index 000..69887c4
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-cm-t43.dts
> @@ -0,0 +1,90 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include
> +#include "am4372.dtsi"
> +
> +/ {
> + model = "CompuLab CM-T43";
> + compatible = "compulab,am437x-cm-t43","ti,am4372","ti,am43";
^
space
[...]
> diff --git a/arch/arm/boot/dts/am437x-sbc-t43.dts
> b/arch/arm/boot/dts/am437x-sbc-t43.dts
> new file mode 100644
> index 000..f3cd76b
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-sbc-t43.dts
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "am437x-cm-t43.dts"
> +
> +/ {
> + model = "CompuLab CM-T43 on SB-SOM-T43";
> + compatible =
> "compulab,am437x-sbc-t43","compulab,am437x-cm-t43","ti,am4372","ti,am43";
spaces
--
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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On 11/25/2015 1:03 PM, Tony Lindgren wrote: > * Arnd Bergmann [151125 11:50]: >> On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: >>> * Pali Rohár [151123 06:46]: On Sunday 22 November 2015 07:51:46 Pavel Machek wrote: > On Wed 2015-11-11 17:10:46, Frank Rowand wrote: >> Adding devicetree list. >> >> Thread starts at >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html >> >> On 11/5/2015 8:17 AM, Tony Lindgren wrote: >>> * Pali Rohár [151105 03:41]: On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: > On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: >> * Pali Rohár [151012 13:29]: >>> On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: Pali, any news on posting an updated series with the comments addressed in this thread? It seems that we all pretty much agree what needs to be done. >> >> I'm not real happy with the concept of patches 4 and 5 in this series. >> My concern is that those two patches are using the FDT as a transport >> mechanism for a binary blob (the atags object). > > Umm. Ok. Do you have alternative proposal that works for everyone? > > I mean. This discussion was going for quite a long time, and it would > be nice to have some solution... patch proposal... something. > Pavel Yes, discussion is going for a long time! So should I spend time for adding documentation to my solution (this is last one thing which is missing)? Or my solution is wrong and somebody else will propose new? I do not want to spend time on something which will be rejected and discarded. >>> >>> At least I don't have better solutions in mind. >> >> I would be happier if we could restrict this as much as possible to the >> boards that need it, as an opt-in. That way it doesn't become an ABI The feature (in whatever form it takes) should be definitely be highly restricted and marked as deprecated. >> for people that don't already rely in this information. How about >> adding a check the code adds the linux,atags property to do it >> only for a whitelist of board numbers? > > Or populate /proc/atags only for the ones that need it from machine > specific init_early? This is circling back to the first comment from Russell King where he suggested a legacy file for the N900 which calls save_atags(): Are the ATAGs at a fixed address on the N900? Can that be handled in some kind of legacy file for the N900 which calls save_atags() on it, so we don't end up introducing yet more stuff that we have to maintain into the distant future? If not, what about copying a known working atag structure into a legacy file for the N900? It seems to me that patches 1, 2, 4, and 5 could be replaced by this approach. Regards, Frank -- 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
