Re: [PATCH 5/5] ARM: OMAP3+: DPLL: use determine_rate() and set_rate_and_parent()
On 12/10/2014 09:41 PM, Kevin Hilman wrote: Hi Tero, On Fri, Oct 3, 2014 at 6:57 AM, Tero Kristo wrote: Currently, DPLLs are hiding the gory details of switching parent within set_rate, which confuses the common clock code and is wrong. Fixed by applying the new determine_rate() and set_rate_and_parent() functionality to any clock-ops previously using the broken approach. This patch also removes the broken legacy code. Signed-off-by: Tero Kristo This patch arrived in linux-next (as commit 2e1a7b014f9c) and broke the omap2plus_defconfig, non-DT boot for the omap3-beagle-xm. By default, there's no output on the console, but turning on DEBUG_LL, I got the crash below[1]. Reverting this commit on next-20141210 gets things booting again for me. Interesting... I'll pull latest linux-next today and try this out. -Tero Kevin [1] [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] Unable to handle kernel paging request at virtual address 5f737973 [0.00] pgd = c0004000 [0.00] [5f737973] *pgd= [0.00] Internal error: Oops: 5 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-11367-g6791358f417e #85 [0.00] Hardware name: OMAP3 Beagle Board [0.00] task: c08da288 ti: c08ce000 task.ti: c08ce000 [0.00] PC is at strcmp+0x4/0x30 [0.00] LR is at clk_fetch_parent_index+0x80/0xd8 [0.00] pc : []lr : []psr: 61d3 [0.00] sp : c08cff20 ip : fp : [0.00] r10: c08ec168 r9 : 5f737973 r8 : 0001 [0.00] r7 : de00d280 r6 : c0770eb4 r5 : de00d284 r4 : [0.00] r3 : 0073 r2 : r1 : 5f737973 r0 : c0770eb5 [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 80004019 DAC: 0015 [0.00] Process swapper/0 (pid: 0, stack limit = 0xc08ce240) [0.00] Stack: (0xc08cff20 to 0xc08d) [0.00] ff20: c08ec168 c0770eb4 c08ebbf0 23c34600 07270e00 413fc082 dfeff140 c04d82b0 [0.00] ff40: c08ebbf0 07270e00 c08ec168 c08ec168 07270e00 001a 23c34600 c08ab890 [0.00] ff60: dfeff140 c04d8bfc 34300133 0190 c08ec168 c086ffc8 34300133 0190 [0.00] ff80: c0870318 0258 c09768c4 c09768c4 c09768c4 0001 [0.00] ffa0: c0976480 c08681a8 c086a114 c08aa1e8 c0862684 0002 c085eb08 [0.00] ffc0: c085e670 c08ab890 c0976694 [0.00] ffe0: c08d6968 c08ab88c c08dbc2c 80004059 80008074 [0.00] [] (strcmp) from [] (clk_fetch_parent_index+0x80/0xd8) [0.00] [] (clk_fetch_parent_index) from [] (clk_calc_new_rates+0x98/0x194) [0.00] [] (clk_calc_new_rates) from [] (clk_set_rate+0x50/0x90) [0.00] [] (clk_set_rate) from [] (omap3_clk_lock_dpll5+0x1c/0xb4) [0.00] [] (omap3_clk_lock_dpll5) from [] (omap3xxx_clk_init+0x2b8/0x398) [0.00] [] (omap3xxx_clk_init) from [] (omap_clk_init+0x3c/0x50) [0.00] [] (omap_clk_init) from [] (omap3_secure_sync32k_timer_init+0x8/0x58) [0.00] [] (omap3_secure_sync32k_timer_init) from [] (time_init+0x1c/0x30) [0.00] [] (time_init) from [] (start_kernel+0x25c/0x3fc) [0.00] [] (start_kernel) from [<80008074>] (0x80008074) [0.00] Code: e12fff1e e1a03000 eaf7 e4d03001 (e4d12001) [ -- 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 5/7] arm: omap: hwmod: allow for registration of class-less hwmods
On Wed, Dec 10, 2014 at 08:54:33AM -0600, Felipe Balbi wrote:
> Hi,
>
> (adding linux-omap back to the loop)
>
> On Wed, Dec 10, 2014 at 04:20:30PM +0530, Lokesh Vutla wrote:
> > Hi Felipe,
> >
> > On Wednesday 10 December 2014 03:57 AM, Felipe Balbi wrote:
> > > Before this patch, HWMOD requires the existence
> > > of a struct omap_hwmod_class very early.
> > Yes, hwmod code looks for omap_hwmod_class entry before registering any
> > hwmod.
> >
> > With the patch 4/7 omap_hwmod_class gets populated from dt very late after
> > registration of the hwmod.
> > So all the hwmod which gets class data from dt never gets registered and
> > state is always UNKNOWN.
> > Mostly making it unusable.
> > IMO this patch just masks the problem.
> >
> > In order to register hwmod we need to populate class data very early.
> > We can populate at the same place as how reg property is being parsed.
> > Call omap_hwmod_init_sysc() in _init() of the particular hwmod:
> > The below diff will help:
> >
> > diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> > b/arch/arm/mach-omap2/omap_hwmod.c
> > index cbb908d..05ecf8a 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod.c
> > @@ -2415,6 +2415,116 @@ static int __init _init_mpu_rt_base(struct
> > omap_hwmod *oh, void *data,
> > return 0;
> > }
> >
> > +static int omap_hwmod_has_sysc_bindings(struct device_node *node)
> > +{
> > + char *properties[] = {
> > + "ti,rev_offs",
> > + "ti,sysc_offs",
> > + "ti,syss_offs",
> > + "ti,sysc_flags",
> > + "ti,srst_udelay",
> > + "ti,idlemodes",
> > + "ti,clockact",
> > + "ti,sysc_type",
> > + NULL
> > + };
> > + char **tmp = properties;
> > +
> > + while (*tmp) {
> > + if (of_property_read_bool(node, *tmp)) {
> > + return true;
> > + }
> > + tmp++;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int omap_hwmod_init_sysc(struct device_node *node,
> > + struct omap_hwmod *oh, int index)
> > +{
> > + struct omap_hwmod_class *class = oh->class;
> > + struct omap_hwmod_class_sysconfig *sysc;
> > + int ret;
> > + int i;
> > + char name[128];
> > + const char *tmp = oh->name;
> > + u32 prop;
> > +
> > + /* if data isn't provided by DT, skip */
> > + if ((class && class->sysc) || !omap_hwmod_has_sysc_bindings(node))
> > + return 0;
> > +
> > + class = kzalloc(sizeof(*class), GFP_KERNEL);
> > + if (!class)
> > + return -ENOMEM;
> > +
> > + i = 0;
> > + while (*tmp) {
> > + if (isalpha(*tmp))
> > + name[i++] = *tmp;
> > + tmp++;
> > + }
> > + name[i] = '\0';
> > +
> > + class->name = kzalloc(sizeof(name), GFP_KERNEL);
> > + if (!class->name)
> > + return -ENOMEM;
> > + strncpy(class->name, name, sizeof(name) - 1);
> > +
> > + sysc = kzalloc(sizeof(*sysc), GFP_KERNEL);
> > + if (!sysc)
> > + return -ENOMEM;
> > +
> > + ret = of_property_read_u32_index(node, "ti,rev_offs", index, &prop);
> > + if (!ret)
> > + sysc->rev_offs = prop;
> > +
> > + ret = of_property_read_u32_index(node, "ti,sysc_offs", index, &prop);
> > + if (!ret)
> > + sysc->sysc_offs = prop;
> > +
> > + ret = of_property_read_u32_index(node, "ti,syss_offs", index, &prop);
> > + if (!ret)
> > + sysc->syss_offs = prop;
> > +
> > + ret = of_property_read_u32_index(node, "ti,sysc_flags", index, &prop);
> > + if (!ret)
> > + sysc->sysc_flags = prop & 0x;
> > +
> > + ret = of_property_read_u32_index(node, "ti,srst_udelay", index, &prop);
> > + if (!ret)
> > + sysc->srst_udelay = prop & 0xff;
> > +
> > + ret = of_property_read_u32_index(node, "ti,idlemodes", index, &prop);
> > + if (!ret)
> > + sysc->idlemodes = prop & 0xff;
> > +
> > + ret = of_property_read_u32_index(node, "ti,clockact", index, &prop);
> > + if (!ret)
> > + sysc->clockact = prop & 0xff;
> > +
> > + ret = of_property_read_u32_index(node, "ti,sysc_type", index, &prop);
> > + if (ret)
> > + prop = 1;
> > +
> > + switch (prop) {
> > + case 2:
> > + sysc->sysc_fields = &omap_hwmod_sysc_type2;
> > + break;
> > + case 3:
> > + sysc->sysc_fields = &omap_hwmod_sysc_type3;
> > + break;
> > + case 1:
> > + default:
> > + sysc->sysc_fields = &omap_hwmod_sysc_type1;
> > + }
> > + class->sysc = sysc;
> > + oh->class = class;
> > +
> > + return 0;
> > +}
> > +
> > /**
> > * _init - initialize internal data for the hwmod @oh
> > * @oh: struct omap_hwmod *
> > @@ -2449,6 +2559,12 @@ static int __init _init(struct omap_hwmod *oh, void
> > *data)
> > else if (np && index)
> > pr_warn("omap_hwmod: %s using broken dt data from %s\n",
> > oh->name, np->name);
> > +
> >
Re: [RFC/PATCH 2/7] arm: omap: devicetree: add new properties for OMAP devices
Hi,
On Wed, Dec 10, 2014 at 09:00:49AM -0600, Felipe Balbi wrote:
> On Wed, Dec 10, 2014 at 04:37:19PM +0530, Lokesh Vutla wrote:
> > On Wednesday 10 December 2014 03:57 AM, Felipe Balbi wrote:
> > > In order to get rid of some more hwmod data, we
> > > introduce a few extra properties to OMAP DT
> > > data in order to be able to pass the needed
> > > information through DT.
> > >
> > > Signed-off-by: Felipe Balbi
> > > ---
> > > Documentation/devicetree/bindings/arm/omap/omap.txt | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> > > b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > > index 4f6a82c..c6b9515 100644
> > > --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> > > +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > > @@ -23,6 +23,13 @@ Optional properties:
> > >during suspend.
> > > - ti,no-reset-on-init: When present, the module should not be reset at
> > > init
> > > - ti,no-idle-on-init: When present, the module should not be idled at
> > > init
> > > +- ti,rev_offs: IP block revision register offset (defaults to 0)
> > > +- ti,sysc_offs: OCP_SYSCONFIG register offset (defaults to 0)
> > > +- ti,syss_offs: OCP_SYSSTATUS register offset (defaults to 0)
> > > +- ti,srst_udelay: Delay needed after a softreset in usecs (defaults to 0)
> > > +- ti,idlemodes: Slave and Master supported idling modes
> > > +- ti,clockact: default value of clock activity bits (defaults to 0)
> > > +- ti,sysc_type: OCP_SYSCONFIG type. Valid types are 1, 2 or 3 (defaults
> > > to 1)
> > Once if all the hwmod data comes to dt it will be very dufficult to see all
> > the data
> > together. Can we separate out hwmod class data like clocks data is
> > separated out into different node
> > or something of the sort like below?
> >
> > ti, hwmod_class {
> > ti,class_name = <>;
>
> this can be done, but I don't want to pass a class name. It's anyways
> just the hwmod name without the digits. For those which are not, I would
> rather change the class name to match.
I did some initial thinking on this some weeks ago, too (and then
was short of time, so I did not continue). My suggestion for the
binding would be:
* OCP_SYSCONFIG (power-management of IP-Cores connected to OMAP processors)
Each IP-Core connected to the bus of OMAP processors has
three registers, which specify the IP-Core's version, its
status and setup of PM features.
Required Properties:
- ti,prcm-type: must be one of the following:
1 for OMAP2+ register style,
2 for OMAP4+ register style,
3 for AM33xx register style
- reg: offset to revision, config and status registers
relative to module base address
Optional Properties:
- ti,idlemodes:bit field of flags (SIDLE)
PRCM_IDLE_FORCE (1 << 0)
PRCM_IDLE_NO (1 << 1)
PRCM_IDLE_SMART (1 << 2)
PRCM_IDLE_SMART_WKUP (1 << 3)
- ti,standbymodes: bit field of flags (MIDLE)
PRCM_STANDBY_FORCE(1 << 0)
PRCM_STANDBY_NO (1 << 1)
PRCM_STANDBY_SMART(1 << 2)
PRCM_STANDBY_SMART_WKUP (1 << 3)
- ti,sysc-has-autoidle:config register has AUTOIDLE bit
- ti,sysc-has-softreset: config register has SOFTRESET bit
- ti,sysc-has-enawakeup: config register has ENAWAKEUP bit
- ti,sysc-has-emufree: config register has EMUFREE bit
- ti,sysc-has-clock-activity: config register has CLOCKACTIVITY bit
- ti,sysc-has-dma-disable: config register has DMADISABLE bit
- ti,sysc-has-reset-status:config register has RESETDONE bit
- ti,syss-has-reset-status:status register has RESETDONE bit
- ti,reset-delay-us: reset delay in us
Example:
ocp {
gpio1: gpio@4831 {
compatible = "ti,omap3-gpio";
... /* IP-Core specific properties */
ti,sysconfig {
ti,prcm-type = <1>;
reg = <0x00>, <0x10>, <0x14>;
ti,idlemodes = <(PRCM_IDLE_FORCE | PRCM_IDLE_NO |
PRCM_IDLE_SMART)>;
ti,sysc-has-enawakeup;
ti,sysc-has-autoidle;
ti,sysc-has-softreset;
ti,syss-has-reset-status;
};
};
};
-- Sebastian
signature.asc
Description: Digital signature
[PATCH] treewide: Convert clockevents_notify to use int cpu
As far as I can tell, there's no value indirecting
the cpu passed to this function via a void *.
Update all the callers and called functions from within
clockevents_notify.
Miscellanea:
Add pr_fmt and convert one printk(KERN_ERR to pr_err
Signed-off-by: Joe Perches
---
arch/arm/mach-omap2/cpuidle44xx.c | 7 +++
arch/arm/mach-tegra/cpuidle-tegra114.c | 4 ++--
arch/arm/mach-tegra/cpuidle-tegra20.c | 8
arch/arm/mach-tegra/cpuidle-tegra30.c | 8
arch/x86/kernel/process.c | 6 +++---
arch/x86/xen/suspend.c | 2 +-
drivers/acpi/acpi_pad.c| 9 +
drivers/acpi/processor_idle.c | 4 ++--
drivers/cpuidle/driver.c | 3 +--
drivers/idle/intel_idle.c | 7 +++
include/linux/clockchips.h | 6 +++---
kernel/sched/idle.c| 4 ++--
kernel/time/clockevents.c | 15 +++
kernel/time/hrtimer.c | 6 ++
kernel/time/tick-broadcast.c | 16
kernel/time/tick-common.c | 16
kernel/time/tick-internal.h| 18 +-
kernel/time/timekeeping.c | 4 ++--
18 files changed, 69 insertions(+), 74 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01e398a..5d50aa1 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -112,7 +112,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
mpuss_can_lose_context = (cx->mpu_state == PWRDM_POWER_RET) &&
(cx->mpu_logic_state == PWRDM_POWER_OFF);
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
/*
* Call idle CPU PM enter notifier chain so that
@@ -169,7 +169,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev->cpu == 0 && mpuss_can_lose_context)
cpu_cluster_pm_exit();
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
fail:
cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
@@ -184,8 +184,7 @@ fail:
*/
static void omap_setup_broadcast_timer(void *arg)
{
- int cpu = smp_processor_id();
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &cpu);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, smp_processor_id());
}
static struct cpuidle_driver omap4_idle_driver = {
diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c
b/arch/arm/mach-tegra/cpuidle-tegra114.c
index f2b586d..3b2fc3f 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra114.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra114.c
@@ -44,7 +44,7 @@ static int tegra114_idle_power_down(struct cpuidle_device
*dev,
tegra_set_cpu_in_lp2();
cpu_pm_enter();
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
call_firmware_op(prepare_idle);
@@ -52,7 +52,7 @@ static int tegra114_idle_power_down(struct cpuidle_device
*dev,
if (call_firmware_op(do_idle, 0) == -ENOSYS)
cpu_suspend(0, tegra30_sleep_cpu_secondary_finish);
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
cpu_pm_exit();
tegra_clear_cpu_in_lp2();
diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c
b/arch/arm/mach-tegra/cpuidle-tegra20.c
index 4f25a7c..ab30758 100644
--- a/arch/arm/mach-tegra/cpuidle-tegra20.c
+++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
@@ -136,11 +136,11 @@ static bool tegra20_cpu_cluster_power_down(struct
cpuidle_device *dev,
if (tegra20_reset_cpu_1() || !tegra_cpu_rail_off_ready())
return false;
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
tegra_idle_lp2_last();
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, dev->cpu);
if (cpu_online(1))
tegra20_wake_cpu1_from_reset();
@@ -153,13 +153,13 @@ static bool tegra20_idle_enter_lp2_cpu_1(struct
cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, dev->cpu);
cpu_suspend(0, tegra20_sleep_cpu_secondary_finish);
tegra20_cpu_clear_resettable();
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EX
Re: BCM2048 bluetooth connected over OMAP serial
Hi,
On Wed, Dec 10, 2014 at 09:56:22PM +0100, Pavel Machek wrote:
> On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
> > On Wed, Dec 10, 2014 at 05:02:42PM +, Arnd Bergmann wrote:
> > > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
> > > >
> > > > So, there's bluetooth chip that's connected to the SoC by UART and some
> > > > GPIOs. What would be right representation in the device tree?
> > > > Something like this?
> > > >
> > > > bluetooth {
> > > > compatible = "broadcom,bcm2048";
> > > > uart = <&uart2>;
> > > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want
> > > > 91 */
> > > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /*
> > > > want 101 */
> > > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> > > > /* want 37 */
> > > > chip-type = >;
> > > > bt-sysclk = <2>;
> > > > reset-gpio-shared = <0>;
> > > > };
> > > >
> > > > Is there some way to prevent OMAP tty driver from binding to the
> > > > device and exporting the device to userspace?
> > >
> > > I think from the driver perspective, you want this to be a tty line
> > > discipline rather than a driver that attaches to the physical
> > > uart.
> > >
> > > For the DT representation, I fear we haven't got a precedent. A uart
> > > phandle sounds reasonable, but there might be other ways to do it
> > > and we should consider if there are better alternatives. It could
> > > possibly be a child node of the uart, but that would require other
> > > infrastructure in the kernel because we don't currently create
> > > devices for those.
> >
> > I think the child node is the way to go; that would match what we do for
> > I2C and SPI. We might need new infrastructure, but I don't think we
> > should treat this differently simlpy because we don't have that yet.
>
> Well, uart in this case looks more like a GPIO than an I2C (no
> addressing, just few wires). And we do phandle for GPIOs.
Right and the devices use I2C for full communication and GPIOs as
helpers. I guess UART counts as full communication and not as helper.
phandle vs child node is not a matter of adressing and btw where is
the difference between "5th gpio on 1st gpio controller" and "5th
address on 1st i2c controller"?
> Actually, the chip also has PCM, analog audio, and "pc compatible?"
> connections, plus some connection to WIFI. So we may need more
> phandles there
This is much harder to solve. I think we don't have a DT binding for
a device, which uses two communication interfaces as the bcm2048
(uart & i2c). OTOH we may just add a slave device for the fm-radio
part like this:
uart {
bcm2048 {
stuff;
};
};
i2c {
bcm2048-radio {
master = <&bcm2048>;
};
};
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCH 1/2] pstore-ram: Fix hangs by using write-combine mappings
On Fri, Sep 12, 2014 at 11:32 AM, Tony Lindgren wrote:
> From: Rob Herring
>
> Currently trying to use pstore on at least ARMs can hang as we're
> mapping the peristent RAM with pgprot_noncached().
>
> On ARMs, pgprot_noncached() will actually make the memory strongly
> ordered, and as the atomic operations pstore uses are implementation
> defined for strongly ordered memory, they may not work. So basically
> atomic operations have undefined behavior on ARM for device or strongly
> ordered memory types.
>
> Let's fix the issue by using write-combine variants for mappings. This
> corresponds to normal, non-cacheable memory on ARM. For many other
> architectures, this change does not change the mapping type as by
> default we have:
>
> #define pgprot_writecombine pgprot_noncached
>
> The reason why pgprot_noncached() was originaly used for pstore
> is because Colin Cross had observed lost
> debug prints right before a device hanging write operation on some
> systems. For the platforms supporting pgprot_noncached(), we can
> add a an optional configuration option to support that. But let's
> get pstore working first before adding new features.
>
> Cc: Arnd Bergmann
> Cc: Anton Vorontsov
> Cc: Colin Cross
> Cc: Kees Cook
> Cc: Olof Johansson
> Cc: Tony Luck
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Rob Herring
> [t...@atomide.com: updated description]
> Signed-off-by: Tony Lindgren
Acked-by: Kees Cook
Please Cc: sta...@vger.kernel.org on this one too.
Thanks!
-Kees
> ---
> fs/pstore/ram_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
> index 9d7b9a8..24f94b0 100644
> --- a/fs/pstore/ram_core.c
> +++ b/fs/pstore/ram_core.c
> @@ -392,7 +392,7 @@ static void *persistent_ram_vmap(phys_addr_t start,
> size_t size)
> page_start = start - offset_in_page(start);
> page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
>
> - prot = pgprot_noncached(PAGE_KERNEL);
> + prot = pgprot_writecombine(PAGE_KERNEL);
>
> pages = kmalloc_array(page_count, sizeof(struct page *), GFP_KERNEL);
> if (!pages) {
> @@ -422,7 +422,7 @@ static void *persistent_ram_iomap(phys_addr_t start,
> size_t size)
> buffer_start_add = buffer_start_add_locked;
> buffer_size_add = buffer_size_add_locked;
>
> - return ioremap(start, size);
> + return ioremap_wc(start, size);
> }
>
> static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
> --
> 2.1.0
>
--
Kees Cook
Chrome OS Security
--
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] pstore-ram: Allow optional mapping with pgprot_noncached
* Kees Cook [141210 13:18]:
> On Tue, Sep 16, 2014 at 1:50 PM, Tony Lindgren wrote:
> > From: Tony Lindgren
> > Date: Thu, 11 Sep 2014 15:02:37 -0700
> > Subject: [PATCH] pstore-ram: Allow optional mapping with pgprot_noncached
> >
> > On some ARMs the memory can be mapped pgprot_noncached() and still
> > be working for atomic operations. As pointed out by Colin Cross
> > , in some cases you do want to use
> > pgprot_noncached() if the SoC supports it to see a debug printk
> > just before a write hanging the system.
> >
> > On ARMs, the atomic operations on strongly ordered memory are
> > implementation defined. So let's provide an optional kernel parameter
> > for configuring pgprot_noncached(), and use pgprot_writecombine() by
> > default.
> >
> > Cc: Arnd Bergmann
> > Cc: Rob Herring
> > Cc: Randy Dunlap
> > Cc: Anton Vorontsov
> > Cc: Colin Cross
> > Cc: Kees Cook
> > Cc: Olof Johansson
> > Cc: Tony Luck
> > Cc: Russell King
> > Signed-off-by: Tony Lindgren
>
> Sorry this got missed! I think rmk's concerns were addressed in this
> v2. Tony (Luck), can you take this into your tree?
>
> Acked-by: Kees Cook
I take your ack covers patch 1/2 also. The first patch in this
series should be tagged cc stable when committing please.
Regards,
Tony
> Thanks!
>
> -Kees
>
> >
> > --- a/Documentation/ramoops.txt
> > +++ b/Documentation/ramoops.txt
> > @@ -14,11 +14,19 @@ survive after a restart.
> >
> > 1. Ramoops concepts
> >
> > -Ramoops uses a predefined memory area to store the dump. The start and
> > size of
> > -the memory area are set using two variables:
> > +Ramoops uses a predefined memory area to store the dump. The start and size
> > +and type of the memory area are set using three variables:
> >* "mem_address" for the start
> >* "mem_size" for the size. The memory size will be rounded down to a
> >power of two.
> > + * "mem_type" to specifiy if the memory type (default is
> > pgprot_writecombine).
> > +
> > +Typically the default value of mem_type=0 should be used as that sets the
> > pstore
> > +mapping to pgprot_writecombine. Setting mem_type=1 attempts to use
> > +pgprot_noncached, which only works on some platforms. This is because
> > pstore
> > +depends on atomic operations. At least on ARM, pgprot_noncached causes the
> > +memory to be mapped strongly ordered, and atomic operations on strongly
> > ordered
> > +memory are implementation defined, and won't work on many ARMs such as
> > omaps.
> >
> > The memory area is divided into "record_size" chunks (also rounded down to
> > power of two) and each oops/panic writes a "record_size" chunk of
> > @@ -55,6 +63,7 @@ Setting the ramoops parameters can be done in 2 different
> > manners:
> > static struct ramoops_platform_data ramoops_data = {
> > .mem_size = <...>,
> > .mem_address= <...>,
> > +.mem_type = <...>,
> > .record_size= <...>,
> > .dump_oops = <...>,
> > .ecc= <...>,
> > --- a/fs/pstore/ram.c
> > +++ b/fs/pstore/ram.c
> > @@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400);
> > MODULE_PARM_DESC(mem_size,
> > "size of reserved RAM used to store oops/panic logs");
> >
> > +static unsigned int mem_type;
> > +module_param(mem_type, uint, 0600);
> > +MODULE_PARM_DESC(mem_type,
> > + "set to 1 to try to use unbuffered memory (default 0)");
> > +
> > static int dump_oops = 1;
> > module_param(dump_oops, int, 0600);
> > MODULE_PARM_DESC(dump_oops,
> > @@ -79,6 +84,7 @@ struct ramoops_context {
> > struct persistent_ram_zone *fprz;
> > phys_addr_t phys_addr;
> > unsigned long size;
> > + unsigned int memtype;
> > size_t record_size;
> > size_t console_size;
> > size_t ftrace_size;
> > @@ -358,7 +364,8 @@ static int ramoops_init_przs(struct device *dev, struct
> > ramoops_context *cxt,
> > size_t sz = cxt->record_size;
> >
> > cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
> > - &cxt->ecc_info);
> > + &cxt->ecc_info,
> > + cxt->memtype);
> > if (IS_ERR(cxt->przs[i])) {
> > err = PTR_ERR(cxt->przs[i]);
> > dev_err(dev, "failed to request mem region
> > (0x%zx@0x%llx): %d\n",
> > @@ -388,7 +395,7 @@ static int ramoops_init_prz(struct device *dev, struct
> > ramoops_context *cxt,
> > return -ENOMEM;
> > }
> >
> > - *prz = persistent_ram_new(*paddr, sz, sig, &cxt->ecc_info);
> > + *prz = persistent_ram_new(*paddr, sz, sig, &cxt->ecc_info,
> > cxt->memtype);
> > if (IS_ERR(*prz)) {
> > int err = PTR_ERR(*prz);
> >
> > @@ -435,6 +442,7 @@ static int ramoops_probe(struct platform_device
Re: [PATCH 2/2] pstore-ram: Allow optional mapping with pgprot_noncached
On Tue, Sep 16, 2014 at 1:50 PM, Tony Lindgren wrote:
> From: Tony Lindgren
> Date: Thu, 11 Sep 2014 15:02:37 -0700
> Subject: [PATCH] pstore-ram: Allow optional mapping with pgprot_noncached
>
> On some ARMs the memory can be mapped pgprot_noncached() and still
> be working for atomic operations. As pointed out by Colin Cross
> , in some cases you do want to use
> pgprot_noncached() if the SoC supports it to see a debug printk
> just before a write hanging the system.
>
> On ARMs, the atomic operations on strongly ordered memory are
> implementation defined. So let's provide an optional kernel parameter
> for configuring pgprot_noncached(), and use pgprot_writecombine() by
> default.
>
> Cc: Arnd Bergmann
> Cc: Rob Herring
> Cc: Randy Dunlap
> Cc: Anton Vorontsov
> Cc: Colin Cross
> Cc: Kees Cook
> Cc: Olof Johansson
> Cc: Tony Luck
> Cc: Russell King
> Signed-off-by: Tony Lindgren
Sorry this got missed! I think rmk's concerns were addressed in this
v2. Tony (Luck), can you take this into your tree?
Acked-by: Kees Cook
Thanks!
-Kees
>
> --- a/Documentation/ramoops.txt
> +++ b/Documentation/ramoops.txt
> @@ -14,11 +14,19 @@ survive after a restart.
>
> 1. Ramoops concepts
>
> -Ramoops uses a predefined memory area to store the dump. The start and size
> of
> -the memory area are set using two variables:
> +Ramoops uses a predefined memory area to store the dump. The start and size
> +and type of the memory area are set using three variables:
>* "mem_address" for the start
>* "mem_size" for the size. The memory size will be rounded down to a
>power of two.
> + * "mem_type" to specifiy if the memory type (default is
> pgprot_writecombine).
> +
> +Typically the default value of mem_type=0 should be used as that sets the
> pstore
> +mapping to pgprot_writecombine. Setting mem_type=1 attempts to use
> +pgprot_noncached, which only works on some platforms. This is because pstore
> +depends on atomic operations. At least on ARM, pgprot_noncached causes the
> +memory to be mapped strongly ordered, and atomic operations on strongly
> ordered
> +memory are implementation defined, and won't work on many ARMs such as omaps.
>
> The memory area is divided into "record_size" chunks (also rounded down to
> power of two) and each oops/panic writes a "record_size" chunk of
> @@ -55,6 +63,7 @@ Setting the ramoops parameters can be done in 2 different
> manners:
> static struct ramoops_platform_data ramoops_data = {
> .mem_size = <...>,
> .mem_address= <...>,
> +.mem_type = <...>,
> .record_size= <...>,
> .dump_oops = <...>,
> .ecc= <...>,
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400);
> MODULE_PARM_DESC(mem_size,
> "size of reserved RAM used to store oops/panic logs");
>
> +static unsigned int mem_type;
> +module_param(mem_type, uint, 0600);
> +MODULE_PARM_DESC(mem_type,
> + "set to 1 to try to use unbuffered memory (default 0)");
> +
> static int dump_oops = 1;
> module_param(dump_oops, int, 0600);
> MODULE_PARM_DESC(dump_oops,
> @@ -79,6 +84,7 @@ struct ramoops_context {
> struct persistent_ram_zone *fprz;
> phys_addr_t phys_addr;
> unsigned long size;
> + unsigned int memtype;
> size_t record_size;
> size_t console_size;
> size_t ftrace_size;
> @@ -358,7 +364,8 @@ static int ramoops_init_przs(struct device *dev, struct
> ramoops_context *cxt,
> size_t sz = cxt->record_size;
>
> cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
> - &cxt->ecc_info);
> + &cxt->ecc_info,
> + cxt->memtype);
> if (IS_ERR(cxt->przs[i])) {
> err = PTR_ERR(cxt->przs[i]);
> dev_err(dev, "failed to request mem region
> (0x%zx@0x%llx): %d\n",
> @@ -388,7 +395,7 @@ static int ramoops_init_prz(struct device *dev, struct
> ramoops_context *cxt,
> return -ENOMEM;
> }
>
> - *prz = persistent_ram_new(*paddr, sz, sig, &cxt->ecc_info);
> + *prz = persistent_ram_new(*paddr, sz, sig, &cxt->ecc_info,
> cxt->memtype);
> if (IS_ERR(*prz)) {
> int err = PTR_ERR(*prz);
>
> @@ -435,6 +442,7 @@ static int ramoops_probe(struct platform_device *pdev)
>
> cxt->size = pdata->mem_size;
> cxt->phys_addr = pdata->mem_address;
> + cxt->memtype = pdata->mem_type;
> cxt->record_size = pdata->record_size;
> cxt->console_size = pdata->console_size;
> cxt->ftrace_size = pdata->ftrace_size;
> @@ -564,6 +572,7 @@ static void ramoops_register_dummy(void)
>
> dummy_data->mem_size = mem_size;
> dummy_data->
[GIT PULL] few fixes for the v3.19 merge window
The following changes since commit a0e4467726cd26bacb16f13d207ffcfa82ffc07d: Merge tag 'asm-generic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic (2014-12-09 17:25:00 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/fixes-for-merge-window for you to fetch changes up to 661ea91b676bcca137c1c3fe838997925ce98060: ARM: omap2plus_defconfig: Enable AHCI_PLATFORM driver (2014-12-10 09:33:50 -0800) Fixes for a few issues found that would be good to get into -rc1: - Update SoC revision detection for am43x es1.2 - Fix regression with GPMC timings on 2430sdp for some versions of u-boot - Fix dra7 watchdog compatible property - Fix am437x-sk-evm LCD timings - Fix dra7 DSS clock muxing - Fix dra7-evm voltages - Remove a unused function prototype for am33xx_clk_init - Enable AHCI in the omap2plus_defconfig Felipe Balbi (1): ARM: dts: am437x-sk: fix lcd enable pin mux data Johan Hovold (1): ARM: OMAP2+: clock: remove unused function prototype Lokesh Vutla (2): ARM: dts: DRA7: wdt: Fix compatible property for watchdog node ARM: OMAP2+: AM43x: Add ID for ES1.2 Ravikumar Kattekola (2): ARM: dts: dra7-evm: Fix typo in SMPS6 (VDD_GPU) max voltage ARM: dts: dra7-evm: Update SMPS7 (VDD_CORE) max voltage to match DM Roger Quadros (1): ARM: omap2plus_defconfig: Enable AHCI_PLATFORM driver Tomi Valkeinen (2): ARM: dts: dra7: fix DSS PLL clock mux registers ARM: dts: am437x-sk-evm.dts: fix LCD timings Tony Lindgren (2): Merge branch 'omap-for-v3.19/fixes-not-urgent' into omap-for-v3.19/fixes ARM: dts: Fix gpmc regression for omap 2430sdp smc91x arch/arm/boot/dts/am437x-sk-evm.dts | 15 +++ arch/arm/boot/dts/dra7-evm.dts | 4 ++-- arch/arm/boot/dts/dra7.dtsi | 2 +- arch/arm/boot/dts/dra72-evm.dts | 2 +- arch/arm/boot/dts/dra7xx-clocks.dtsi | 6 +++--- arch/arm/boot/dts/omap2430-sdp.dts | 32 arch/arm/configs/omap2plus_defconfig | 2 ++ arch/arm/mach-omap2/clock.h | 2 -- arch/arm/mach-omap2/id.c | 8 ++-- arch/arm/mach-omap2/soc.h| 1 + 10 files changed, 39 insertions(+), 35 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: BCM2048 bluetooth connected over OMAP serial
On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
> On Wed, Dec 10, 2014 at 05:02:42PM +, Arnd Bergmann wrote:
> > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
> > >
> > > So, there's bluetooth chip that's connected to the SoC by UART and some
> > > GPIOs. What would be right representation in the device tree?
> > > Something like this?
> > >
> > > bluetooth {
> > > compatible = "broadcom,bcm2048";
> > > uart = <&uart2>;
> > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91
> > > */
> > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /*
> > > want 101 */
> > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> > > /* want 37 */
> > > chip-type = >;
> > > bt-sysclk = <2>;
> > > reset-gpio-shared = <0>;
> > > };
> > >
> > > Is there some way to prevent OMAP tty driver from binding to the
> > > device and exporting the device to userspace?
> >
> > I think from the driver perspective, you want this to be a tty line
> > discipline rather than a driver that attaches to the physical
> > uart.
> >
> > For the DT representation, I fear we haven't got a precedent. A uart
> > phandle sounds reasonable, but there might be other ways to do it
> > and we should consider if there are better alternatives. It could
> > possibly be a child node of the uart, but that would require other
> > infrastructure in the kernel because we don't currently create
> > devices for those.
>
> I think the child node is the way to go; that would match what we do for
> I2C and SPI. We might need new infrastructure, but I don't think we
> should treat this differently simlpy because we don't have that yet.
Well, uart in this case looks more like a GPIO than an I2C (no
addressing, just few wires). And we do phandle for GPIOs.
Actually, the chip also has PCM, analog audio, and "pc compatible?"
connections, plus some connection to WIFI. So we may need more
phandles there
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 5/5] ARM: OMAP3+: DPLL: use determine_rate() and set_rate_and_parent()
Hi Tero, On Fri, Oct 3, 2014 at 6:57 AM, Tero Kristo wrote: > Currently, DPLLs are hiding the gory details of switching parent > within set_rate, which confuses the common clock code and is wrong. > Fixed by applying the new determine_rate() and set_rate_and_parent() > functionality to any clock-ops previously using the broken approach. > This patch also removes the broken legacy code. > > Signed-off-by: Tero Kristo This patch arrived in linux-next (as commit 2e1a7b014f9c) and broke the omap2plus_defconfig, non-DT boot for the omap3-beagle-xm. By default, there's no output on the console, but turning on DEBUG_LL, I got the crash below[1]. Reverting this commit on next-20141210 gets things booting again for me. Kevin [1] [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz [0.00] Unable to handle kernel paging request at virtual address 5f737973 [0.00] pgd = c0004000 [0.00] [5f737973] *pgd= [0.00] Internal error: Oops: 5 [#1] SMP ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-11367-g6791358f417e #85 [0.00] Hardware name: OMAP3 Beagle Board [0.00] task: c08da288 ti: c08ce000 task.ti: c08ce000 [0.00] PC is at strcmp+0x4/0x30 [0.00] LR is at clk_fetch_parent_index+0x80/0xd8 [0.00] pc : []lr : []psr: 61d3 [0.00] sp : c08cff20 ip : fp : [0.00] r10: c08ec168 r9 : 5f737973 r8 : 0001 [0.00] r7 : de00d280 r6 : c0770eb4 r5 : de00d284 r4 : [0.00] r3 : 0073 r2 : r1 : 5f737973 r0 : c0770eb5 [0.00] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 10c5387d Table: 80004019 DAC: 0015 [0.00] Process swapper/0 (pid: 0, stack limit = 0xc08ce240) [0.00] Stack: (0xc08cff20 to 0xc08d) [0.00] ff20: c08ec168 c0770eb4 c08ebbf0 23c34600 07270e00 413fc082 dfeff140 c04d82b0 [0.00] ff40: c08ebbf0 07270e00 c08ec168 c08ec168 07270e00 001a 23c34600 c08ab890 [0.00] ff60: dfeff140 c04d8bfc 34300133 0190 c08ec168 c086ffc8 34300133 0190 [0.00] ff80: c0870318 0258 c09768c4 c09768c4 c09768c4 0001 [0.00] ffa0: c0976480 c08681a8 c086a114 c08aa1e8 c0862684 0002 c085eb08 [0.00] ffc0: c085e670 c08ab890 c0976694 [0.00] ffe0: c08d6968 c08ab88c c08dbc2c 80004059 80008074 [0.00] [] (strcmp) from [] (clk_fetch_parent_index+0x80/0xd8) [0.00] [] (clk_fetch_parent_index) from [] (clk_calc_new_rates+0x98/0x194) [0.00] [] (clk_calc_new_rates) from [] (clk_set_rate+0x50/0x90) [0.00] [] (clk_set_rate) from [] (omap3_clk_lock_dpll5+0x1c/0xb4) [0.00] [] (omap3_clk_lock_dpll5) from [] (omap3xxx_clk_init+0x2b8/0x398) [0.00] [] (omap3xxx_clk_init) from [] (omap_clk_init+0x3c/0x50) [0.00] [] (omap_clk_init) from [] (omap3_secure_sync32k_timer_init+0x8/0x58) [0.00] [] (omap3_secure_sync32k_timer_init) from [] (time_init+0x1c/0x30) [0.00] [] (time_init) from [] (start_kernel+0x25c/0x3fc) [0.00] [] (start_kernel) from [<80008074>] (0x80008074) [0.00] Code: e12fff1e e1a03000 eaf7 e4d03001 (e4d12001) [ -- 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: BCM2048 bluetooth connected over OMAP serial
On Wed, Dec 10, 2014 at 05:02:42PM +, Arnd Bergmann wrote:
> On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
> >
> > So, there's bluetooth chip that's connected to the SoC by UART and some
> > GPIOs. What would be right representation in the device tree?
> > Something like this?
> >
> > bluetooth {
> > compatible = "broadcom,bcm2048";
> > uart = <&uart2>;
> > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want
> > 101 */
> > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /*
> > want 37 */
> > chip-type = >;
> > bt-sysclk = <2>;
> > reset-gpio-shared = <0>;
> > };
> >
> > Is there some way to prevent OMAP tty driver from binding to the
> > device and exporting the device to userspace?
>
> I think from the driver perspective, you want this to be a tty line
> discipline rather than a driver that attaches to the physical
> uart.
>
> For the DT representation, I fear we haven't got a precedent. A uart
> phandle sounds reasonable, but there might be other ways to do it
> and we should consider if there are better alternatives. It could
> possibly be a child node of the uart, but that would require other
> infrastructure in the kernel because we don't currently create
> devices for those.
I think the child node is the way to go; that would match what we do for
I2C and SPI. We might need new infrastructure, but I don't think we
should treat this differently simlpy because we don't have that yet.
Mark.
--
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 0/5] irqchip: kill the GIC routable domain
On 12/09/2014 12:40 PM, Marc Zyngier wrote:
> On 09/12/14 18:17, Nishanth Menon wrote:
>> On 09:53-20141209, Marc Zyngier wrote:
>>> On 08/12/14 22:41, Nishanth Menon wrote:
>>>
Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
assume you will squash as needed and repost with linux-omap mailing list
in CC.
>>>
>>> Brilliant. I'll squash that into my tree and repost at some point.
>>
>> K, it will be nice to have a reflow of the series based on v3.19-rc1
>> since there are dts dependencies and we dont want folks to have
>> regressions on their platforms of choice..
>>
>> Obviously, my tests are basic boot tests and should get a few weeks(as
>> you already mentioned) on linux-next to get properly soaked
>>
>>>
I increased the scope of testing knowing that WUGEN is present in many
A9 based TI platforms as well.. and at least OMAP4 showed flakiness in
my testing.. Also a few notes:
Stuff like: am437x is a bit questionable (interrupt-parent probably should
be wugen?)
175: 0 GIC 39 tps65218
OMAP5: (should be wugen?)
308: 4323 0 GIC 106 OMAP UART2
411: 0 0 GIC 151 twl6040
405: 1 0 GIC 39 palmas
>>>
>>> Well, I can't really tell. Someone with access to the documentation
>>> should be able to find out.
>>
>> AM437x: http://www.ti.com/lit/pdf/spruhl7
>> OMAP5: http://www.ti.com/lit/pdf/swpu249
>>
>> yeah, we should be able to do them as well - trivially since they follow
>> the same structure as other SoCs without crossbar.
>
> Done some stuff in that department.
>
>>>
OMAP4 serial port is flaky -> not sure if it is due to routing of GIC to
UART2 and not via WUGEN
IRQ branch: with my fix applied:
-
>>>
>>> [...]
>>>
18: pandaboard-es: Boot FAIL: http://slexy.org/raw/s20ty0Z6i5 (not
expected)
19: pandaboard-vanilla: Boot FAIL: http://slexy.org/raw/s20BYfaMd2 (not
expected)
>>>
>>> If I read the log correctly, the serial port stops responding after a while?
>>
>> yeah - dug at the omap4 ones a bit, obviously once the deeper c states
>> are hit, we'd like wakeupgen to wakeup CPU else we will be "sluggish" in
>> the sense that the event is detected when some other wakeupgen enabled
>> interrupt takes place.
>
> I realised that as well once I got a panda up and running.
>
>> Adding the following makes my panda work fine.
>> 1: pandaboard-es: Boot PASS: http://slexy.org/raw/s20o8DaBvh
>> 2: pandaboard-vanilla: Boot PASS: http://slexy.org/raw/s222JndDdh
>>
>>
>> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> index 1505135..8b6d50e 100644
>> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
>> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
>> @@ -371,8 +371,8 @@
>> twl: twl@48 {
>> reg = <0x48>;
>> /* IRQ# = 7 */
>> -interrupts = ; /* IRQ_SYS_1N
>> cascaded to gic */
>> -interrupt-parent = <&gic>;
>> +interrupts = ; /* IRQ_SYS_1N
>> cascaded to wakeupgen to gic */
>> +interrupt-parent = <&wakeupgen>;
>> };
>
> [...]
>
> I already fixed those in my tree, in a slightly different way: no need
> to have an interrupt parent at all, as we're going to inherit the
> default anyway.
>
> I've pushed another version of the branch, with the crossbar rework
> sitting *before* the WUGEN hacks. That should hopefully make bisection work.
>
> If you can give it a shake, that'd be most appreciated. I'll repost the
> branch in a couple of days.
>
Did a quick run.. and thought of testing power management and found
that CPUFreq for my platforms are broken in v3.18-rc7 and my scripts
broke (so much for my cronjob testing daily boot... now I gotta add
some PM test as well.. Sigh..) anyways.. just boot log..
based on
irq/die-gic-arch-extn-die-die-die c0024cb irqchip: gic: Drop support
for gic_arch_extn
1: am335x-evm: Boot PASS: http://slexy.org/raw/s201YeK4dW
2: am335x-sk: Boot PASS: http://slexy.org/raw/s20nydiyVx
3: am3517-evm: Boot PASS: http://slexy.org/raw/s2aTrenePo
4: am437x-sk: Boot FAIL: http://slexy.org/raw/s20NNiEa4W
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2gghhhyOy
6: am43xx-gpevm: Boot PASS: http://slexy.org/raw/s2LY4Cb75N
7: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2e8iJMUXu
8: beagleboard-vanilla: Boot PASS: http://slexy.org/raw/s20wqxUmvr
9: beaglebone-black: Boot PASS: http://slexy.org/raw/s21I0g2Ba3
10: beaglebone: Boot PASS: http://slexy.org/raw/s2lpED0qW4
11: craneboard: Boot PASS: http://slexy.org/raw/s230RKflY3
12: dra72x-evm: Boot FAIL: http://slexy.org/raw/s21fWVnjaB
13: dra7xx-evm: Boot PASS: http://slexy.org/raw/s20yEhfruO
14: OMAP3430-Labrador(LDP): Boot PASS: http://slexy.org/raw/s20qZaXwz0
15: n900: Boot PASS: http://slexy.org/raw/s21LNTXZP7
16: omap5
[PATCH] spi/omap100k: Convert to runtime PM
Currently the omap100k driver uses prepare and unprepare transfer hardware
to enable and disable clocks for the IP block. Since these functions are
called along with runtime PM and end up duplicating its functionality in a
less flexible fashion we are trying to phase them out so convert this
driver to do runtime PM instead.
While doing so add missing error handling and remove a redundant NULL
assignment.
Signed-off-by: Mark Brown
---
drivers/spi/spi-omap-100k.c | 101 +---
1 file changed, 77 insertions(+), 24 deletions(-)
diff --git a/drivers/spi/spi-omap-100k.c b/drivers/spi/spi-omap-100k.c
index 79399ae9c84c..ea70494aae12 100644
--- a/drivers/spi/spi-omap-100k.c
+++ b/drivers/spi/spi-omap-100k.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -299,16 +300,6 @@ static int omap1_spi100k_setup(struct spi_device *spi)
return ret;
}
-static int omap1_spi100k_prepare_hardware(struct spi_master *master)
-{
- struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
-
- clk_prepare_enable(spi100k->ick);
- clk_prepare_enable(spi100k->fck);
-
- return 0;
-}
-
static int omap1_spi100k_transfer_one_message(struct spi_master *master,
struct spi_message *m)
{
@@ -377,16 +368,6 @@ static int omap1_spi100k_transfer_one_message(struct
spi_master *master,
return status;
}
-static int omap1_spi100k_unprepare_hardware(struct spi_master *master)
-{
- struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
-
- clk_disable_unprepare(spi100k->ick);
- clk_disable_unprepare(spi100k->fck);
-
- return 0;
-}
-
static int omap1_spi100k_probe(struct platform_device *pdev)
{
struct spi_master *master;
@@ -407,14 +388,12 @@ static int omap1_spi100k_probe(struct platform_device
*pdev)
master->setup = omap1_spi100k_setup;
master->transfer_one_message = omap1_spi100k_transfer_one_message;
- master->prepare_transfer_hardware = omap1_spi100k_prepare_hardware;
- master->unprepare_transfer_hardware = omap1_spi100k_unprepare_hardware;
- master->cleanup = NULL;
master->num_chipselect = 2;
master->mode_bits = MODEBITS;
master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
master->min_speed_hz = OMAP1_SPI100K_MAX_FREQ/(1<<16);
master->max_speed_hz = OMAP1_SPI100K_MAX_FREQ;
+ master->auto_runtime_pm = true;
spi100k = spi_master_get_devdata(master);
@@ -439,22 +418,96 @@ static int omap1_spi100k_probe(struct platform_device
*pdev)
goto err;
}
+ status = clk_prepare_enable(spi100k->ick);
+ if (status != 0) {
+ dev_err(&pdev->dev, "failed to enable ick: %d\n", status);
+ goto err;
+ }
+
+ status = clk_prepare_enable(spi100k->fck);
+ if (status != 0) {
+ dev_err(&pdev->dev, "failed to enable fck: %d\n", status);
+ goto err_ick;
+ }
+
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+
status = devm_spi_register_master(&pdev->dev, master);
if (status < 0)
- goto err;
+ goto err_fck;
return status;
+err_fck:
+ clk_disable_unprepare(spi100k->fck);
+err_ick:
+ clk_disable_unprepare(spi100k->ick);
err:
spi_master_put(master);
return status;
}
+static int omap1_spi100k_remove(struct platform_device *pdev)
+{
+ struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+ struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
+
+ pm_runtime_disable(&pdev->dev);
+
+ clk_disable_unprepare(spi100k->fck);
+ clk_disable_unprepare(spi100k->ick);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int omap1_spi100k_runtime_suspend(struct device *dev)
+{
+ struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
+
+ clk_disable_unprepare(spi100k->ick);
+ clk_disable_unprepare(spi100k->fck);
+
+ return 0;
+}
+
+static int omap1_spi100k_runtime_resume(struct device *dev)
+{
+ struct spi_master *master = spi_master_get(dev_get_drvdata(dev));
+ struct omap1_spi100k *spi100k = spi_master_get_devdata(master);
+ int ret;
+
+ ret = clk_prepare_enable(spi100k->ick);
+ if (ret != 0) {
+ dev_err(dev, "Failed to enable ick: %d\n", ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(spi100k->fck);
+ if (ret != 0) {
+ dev_err(dev, "Failed to enable fck: %d\n", ret);
+ clk_disable_unprepare(spi100k->ick);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops omap1_spi100k_pm = {
+ SET_RUNTIME_PM_OPS(omap
Re: BCM2048 bluetooth connected over OMAP serial
Hi Rob,
>> So, there's bluetooth chip that's connected to the SoC by UART and some
>> GPIOs. What would be right representation in the device tree?
>> Something like this?
>>
>>bluetooth {
>> compatible = "broadcom,bcm2048";
>> uart = <&uart2>;
>> reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
>> host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want
>> 101 */
>> bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /*
>> want 37 */
>> chip-type = <3>;
>> bt-sysclk = <2>;
>> reset-gpio-shared = <0>;
>>};
>>
>> Is there some way to prevent OMAP tty driver from binding to the
>> device and exporting the device to userspace?
>
> Isn't the normal way for BT to work is the uart is exposed to
> userspace and the BT stack is all in userspace? This is how other
> Broadcom BT/WiFi combo parts work.
not on Linux actually. The Bluetooth core layer (including the HCI transport)
are all in kernel space.
However UART based Bluetooth chips are exposed as TTY and then the N_HCI line
discipline is used to attach it to the kernel Bluetooth subsystem.
Regards
Marcel
--
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: BCM2048 bluetooth connected over OMAP serial
On Wed, Dec 10, 2014 at 10:43 AM, Pavel Machek wrote:
> Hi!
>
> So, there's bluetooth chip that's connected to the SoC by UART and some
> GPIOs. What would be right representation in the device tree?
> Something like this?
>
> bluetooth {
> compatible = "broadcom,bcm2048";
> uart = <&uart2>;
> reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want
> 101 */
> bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /*
> want 37 */
> chip-type = <3>;
> bt-sysclk = <2>;
> reset-gpio-shared = <0>;
> };
>
> Is there some way to prevent OMAP tty driver from binding to the
> device and exporting the device to userspace?
Isn't the normal way for BT to work is the uart is exposed to
userspace and the BT stack is all in userspace? This is how other
Broadcom BT/WiFi combo parts work.
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] ARM: omap2plus_defconfig: Enable AHCI_PLATFORM driver
* Roger Quadros [141124 03:43]: > OMAP5 and DRA7 platforms need the AHCI platform driver > for SATA support. > > Signed-off-by: Roger Quadros Applying into omap-for-v3.19/fixes to get this working. Tony > --- > arch/arm/configs/omap2plus_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/omap2plus_defconfig > b/arch/arm/configs/omap2plus_defconfig > index 87a5c11..d75358a 100644 > --- a/arch/arm/configs/omap2plus_defconfig > +++ b/arch/arm/configs/omap2plus_defconfig > @@ -127,6 +127,8 @@ CONFIG_SRAM=y > CONFIG_SCSI=y > CONFIG_BLK_DEV_SD=y > CONFIG_SCSI_SCAN_ASYNC=y > +CONFIG_ATA=y > +CONFIG_SATA_AHCI_PLATFORM=y > CONFIG_MD=y > CONFIG_NETDEVICES=y > # CONFIG_NET_VENDOR_ARC is not set > -- > 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] ARM: dts: am437x-sk-evm.dts: fix LCD timings
* Tomi Valkeinen [141204 23:42]:
> The lcd0 node for am437x-sk-evm.dts contains bad LCD timings, and while
> they seem to work with a quick test, doing for example blank/unblank
> will give you a black display.
>
> This patch updates the timings to the 'typical' values from the LCD spec
> sheet.
>
> Also, the compatible string is completely bogus, as
> "osddisplays,osd057T0559-34ts" is _not_ a 480x272 panel. The panel on
> the board is a newhaven one. Update the compatible string to reflect
> this. Note that this hasn't caused any issues, as the "panel-dpi"
> matches the driver.
>
> Cc: # v3.17+
> Tested-by: Felipe Balbi
> Signed-off-by: Tomi Valkeinen
Applying into omap-for-v3.19/fixes thanks.
Tony
> ---
> arch/arm/boot/dts/am437x-sk-evm.dts | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> b/arch/arm/boot/dts/am437x-sk-evm.dts
> index 859ff3d620ee..66071c7b3dde 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -100,7 +100,7 @@
> };
>
> lcd0: display {
> - compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
> + compatible = "newhaven,nhd-4.3-480272ef-atxl", "panel-dpi";
> label = "lcd";
>
> pinctrl-names = "default";
> @@ -112,11 +112,11 @@
> clock-frequency = <900>;
> hactive = <480>;
> vactive = <272>;
> - hfront-porch = <8>;
> - hback-porch = <43>;
> - hsync-len = <4>;
> - vback-porch = <12>;
> - vfront-porch = <4>;
> + hfront-porch = <2>;
> + hback-porch = <2>;
> + hsync-len = <41>;
> + vfront-porch = <2>;
> + vback-porch = <2>;
> vsync-len = <10>;
> hsync-active = <0>;
> vsync-active = <0>;
> --
> 2.2.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: BCM2048 bluetooth connected over OMAP serial
On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
>
> So, there's bluetooth chip that's connected to the SoC by UART and some
> GPIOs. What would be right representation in the device tree?
> Something like this?
>
> bluetooth {
> compatible = "broadcom,bcm2048";
> uart = <&uart2>;
> reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want
> 101 */
> bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /*
> want 37 */
> chip-type = >;
> bt-sysclk = <2>;
> reset-gpio-shared = <0>;
> };
>
> Is there some way to prevent OMAP tty driver from binding to the
> device and exporting the device to userspace?
I think from the driver perspective, you want this to be a tty line
discipline rather than a driver that attaches to the physical
uart.
For the DT representation, I fear we haven't got a precedent. A uart
phandle sounds reasonable, but there might be other ways to do it
and we should consider if there are better alternatives. It could
possibly be a child node of the uart, but that would require other
infrastructure in the kernel because we don't currently create
devices for those.
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 0/2] ARM: dts: dra7-evm: Regulator max voltage fixes
* Nishanth Menon [141203 05:06]:
> On 12/03/2014 06:03 AM, Ravikumar Kattekola wrote:
> > Hi,
> >
> > This set does a minor fix and an update:
> >
> >- Fix a typo in the max voltage property of smps6 (vdd_gpu) regulator
> > node added by
> > the patch : c56a831ca47e ("ARM: dts: DRA7: Add TPS659038 PMIC nodes")
> >
> >- Update max voltage property of smps7 (vdd_core) regulator node to
> > align with the
> > latest Data Manual
> >
> > Regards,
> > RK
> >
> > Ravikumar Kattekola (2):
> > ARM: dts: dra7-evm: Fix typo in SMPS6 (VDD_GPU) max voltage
> > ARM: dts: dra7-evm: Update SMPS7 (VDD_CORE) max voltage to match DM
> >
> > arch/arm/boot/dts/dra7-evm.dts |4 ++--
> > arch/arm/boot/dts/dra72-evm.dts |2 +-
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> These apply to
>
> https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/?h=omap-for-v3.19/dt-v2
>
> Acked-by: Nishanth Menon
Applying both into omap-for-v3.19/fixes thanks.
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: OMAP2+: AM43x: Add ID for ES1.2
* Nishanth Menon [141202 08:51]: > On 11/27/2014 09:32 PM, Lokesh Vutla wrote: > > ES1.2 is a minor variant of ES1.1. Major changes since ES1.1 are > > updating ROM for fixing the following boot modes: > > - NAND boot > > - UART boot > > - Ethernet boot > > - USB HOST/Client boot > > This patch adds ID support for AM437x ES1.2 silicon. > > There are no additional kernel fixes required for ES1.2 silicon. > > > > Latest Technical Documentation can be found here: > > http://www.ti.com/lsds/ti/arm/sitara_arm_cortex_a_processor/arm_cortex_a9_core/am437x_arm_cortex_a9/tech_docs.page > > > > Signed-off-by: Lokesh Vutla > > --- > > arch/arm/mach-omap2/id.c | 8 ++-- > > arch/arm/mach-omap2/soc.h | 1 + > > 2 files changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > > index 53841de..c25feba 100644 > > --- a/arch/arm/mach-omap2/id.c > > +++ b/arch/arm/mach-omap2/id.c > > @@ -471,11 +471,15 @@ void __init omap3xxx_check_revision(void) > > cpu_rev = "1.0"; > > break; > > case 1: > > - /* FALLTHROUGH */ > > - default: > > omap_revision = AM437X_REV_ES1_1; > > cpu_rev = "1.1"; > > break; > > + case 2: > > + /* FALLTHROUGH */ > > + default: > > + omap_revision = AM437X_REV_ES1_2; > > + cpu_rev = "1.2"; > > + break; > > } > > break; > > case 0xb8f2: > > diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h > > index 4376f59..c1a3b44 100644 > > --- a/arch/arm/mach-omap2/soc.h > > +++ b/arch/arm/mach-omap2/soc.h > > @@ -446,6 +446,7 @@ IS_OMAP_TYPE(3430, 0x3430) > > #define AM437X_CLASS 0x4370 > > #define AM437X_REV_ES1_0 (AM437X_CLASS | (0x10 << 8)) > > #define AM437X_REV_ES1_1 (AM437X_CLASS | (0x11 << 8)) > > +#define AM437X_REV_ES1_2 (AM437X_CLASS | (0x12 << 8)) > > > > #define OMAP443X_CLASS 0x44300044 > > #define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 << 8)) > > > > Reviewed-by: Nishanth Menon Applying into omap-for-v3.19/fixes thanks. 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
BCM2048 bluetooth connected over OMAP serial
Hi!
So, there's bluetooth chip that's connected to the SoC by UART and some
GPIOs. What would be right representation in the device tree?
Something like this?
bluetooth {
compatible = "broadcom,bcm2048";
uart = <&uart2>;
reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101
*/
bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want
37 */
chip-type = <3>;
bt-sysclk = <2>;
reset-gpio-shared = <0>;
};
Is there some way to prevent OMAP tty driver from binding to the
device and exporting the device to userspace?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: boot: dts: am437x-sk: fix lcd enable pin mux data
* Felipe Balbi [141204 07:12]:
> Caused by a copy & paste error. Note that even with
> this bug AM437x SK display still works because GPIO
> mux mode is always enabled. It's still wrong to mux
> somebody else's pin.
>
> Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
> isn't used for anything.
>
> While at that, also replace a pullup with a pulldown
> as that gpio should be normally low, not high.
>
> Cc: # v3.17+
> Acked-by: Tomi Valkeinen
> Signed-off-by: Felipe Balbi
Applying into omap-for-v3.19/fixes thanks.
Tony
> ---
> arch/arm/boot/dts/am437x-sk-evm.dts | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> b/arch/arm/boot/dts/am437x-sk-evm.dts
> index f7f77a7..0eceb8a 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -320,8 +320,7 @@
>
> lcd_pins: lcd_pins {
> pinctrl-single,pins = <
> - /* GPIO 5_8 to select LCD / HDMI */
> - 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
> + 0x1c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
> gpcm_ad7.gpio1_7 */
> >;
> };
> };
> --
> 2.1.0.GIT
>
--
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 2/7] arm: omap: devicetree: add new properties for OMAP devices
Hi,
On Wed, Dec 10, 2014 at 04:37:19PM +0530, Lokesh Vutla wrote:
> Hi Felipe,
>
> On Wednesday 10 December 2014 03:57 AM, Felipe Balbi wrote:
> > In order to get rid of some more hwmod data, we
> > introduce a few extra properties to OMAP DT
> > data in order to be able to pass the needed
> > information through DT.
> >
> > Signed-off-by: Felipe Balbi
> > ---
> > Documentation/devicetree/bindings/arm/omap/omap.txt | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> > b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > index 4f6a82c..c6b9515 100644
> > --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> > +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > @@ -23,6 +23,13 @@ Optional properties:
> >during suspend.
> > - ti,no-reset-on-init: When present, the module should not be reset at init
> > - ti,no-idle-on-init: When present, the module should not be idled at init
> > +- ti,rev_offs: IP block revision register offset (defaults to 0)
> > +- ti,sysc_offs: OCP_SYSCONFIG register offset (defaults to 0)
> > +- ti,syss_offs: OCP_SYSSTATUS register offset (defaults to 0)
> > +- ti,srst_udelay: Delay needed after a softreset in usecs (defaults to 0)
> > +- ti,idlemodes: Slave and Master supported idling modes
> > +- ti,clockact: default value of clock activity bits (defaults to 0)
> > +- ti,sysc_type: OCP_SYSCONFIG type. Valid types are 1, 2 or 3 (defaults to
> > 1)
> Once if all the hwmod data comes to dt it will be very dufficult to see all
> the data
> together. Can we separate out hwmod class data like clocks data is separated
> out into different node
> or something of the sort like below?
>
> ti, hwmod_class {
> ti,class_name = <>;
this can be done, but I don't want to pass a class name. It's anyways
just the hwmod name without the digits. For those which are not, I would
rather change the class name to match.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC/PATCH 5/7] arm: omap: hwmod: allow for registration of class-less hwmods
Hi,
(adding linux-omap back to the loop)
On Wed, Dec 10, 2014 at 04:20:30PM +0530, Lokesh Vutla wrote:
> Hi Felipe,
>
> On Wednesday 10 December 2014 03:57 AM, Felipe Balbi wrote:
> > Before this patch, HWMOD requires the existence
> > of a struct omap_hwmod_class very early.
> Yes, hwmod code looks for omap_hwmod_class entry before registering any hwmod.
>
> With the patch 4/7 omap_hwmod_class gets populated from dt very late after
> registration of the hwmod.
> So all the hwmod which gets class data from dt never gets registered and
> state is always UNKNOWN.
> Mostly making it unusable.
> IMO this patch just masks the problem.
>
> In order to register hwmod we need to populate class data very early.
> We can populate at the same place as how reg property is being parsed.
> Call omap_hwmod_init_sysc() in _init() of the particular hwmod:
> The below diff will help:
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c
> b/arch/arm/mach-omap2/omap_hwmod.c
> index cbb908d..05ecf8a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -2415,6 +2415,116 @@ static int __init _init_mpu_rt_base(struct omap_hwmod
> *oh, void *data,
> return 0;
> }
>
> +static int omap_hwmod_has_sysc_bindings(struct device_node *node)
> +{
> + char *properties[] = {
> + "ti,rev_offs",
> + "ti,sysc_offs",
> + "ti,syss_offs",
> + "ti,sysc_flags",
> + "ti,srst_udelay",
> + "ti,idlemodes",
> + "ti,clockact",
> + "ti,sysc_type",
> + NULL
> + };
> + char **tmp = properties;
> +
> + while (*tmp) {
> + if (of_property_read_bool(node, *tmp)) {
> + return true;
> + }
> + tmp++;
> + }
> +
> + return 0;
> +}
> +
> +static int omap_hwmod_init_sysc(struct device_node *node,
> + struct omap_hwmod *oh, int index)
> +{
> + struct omap_hwmod_class *class = oh->class;
> + struct omap_hwmod_class_sysconfig *sysc;
> + int ret;
> + int i;
> + char name[128];
> + const char *tmp = oh->name;
> + u32 prop;
> +
> + /* if data isn't provided by DT, skip */
> + if ((class && class->sysc) || !omap_hwmod_has_sysc_bindings(node))
> + return 0;
> +
> + class = kzalloc(sizeof(*class), GFP_KERNEL);
> + if (!class)
> + return -ENOMEM;
> +
> + i = 0;
> + while (*tmp) {
> + if (isalpha(*tmp))
> + name[i++] = *tmp;
> + tmp++;
> + }
> + name[i] = '\0';
> +
> + class->name = kzalloc(sizeof(name), GFP_KERNEL);
> + if (!class->name)
> + return -ENOMEM;
> + strncpy(class->name, name, sizeof(name) - 1);
> +
> + sysc = kzalloc(sizeof(*sysc), GFP_KERNEL);
> + if (!sysc)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32_index(node, "ti,rev_offs", index, &prop);
> + if (!ret)
> + sysc->rev_offs = prop;
> +
> + ret = of_property_read_u32_index(node, "ti,sysc_offs", index, &prop);
> + if (!ret)
> + sysc->sysc_offs = prop;
> +
> + ret = of_property_read_u32_index(node, "ti,syss_offs", index, &prop);
> + if (!ret)
> + sysc->syss_offs = prop;
> +
> + ret = of_property_read_u32_index(node, "ti,sysc_flags", index, &prop);
> + if (!ret)
> + sysc->sysc_flags = prop & 0x;
> +
> + ret = of_property_read_u32_index(node, "ti,srst_udelay", index, &prop);
> + if (!ret)
> + sysc->srst_udelay = prop & 0xff;
> +
> + ret = of_property_read_u32_index(node, "ti,idlemodes", index, &prop);
> + if (!ret)
> + sysc->idlemodes = prop & 0xff;
> +
> + ret = of_property_read_u32_index(node, "ti,clockact", index, &prop);
> + if (!ret)
> + sysc->clockact = prop & 0xff;
> +
> + ret = of_property_read_u32_index(node, "ti,sysc_type", index, &prop);
> + if (ret)
> + prop = 1;
> +
> + switch (prop) {
> + case 2:
> + sysc->sysc_fields = &omap_hwmod_sysc_type2;
> + break;
> + case 3:
> + sysc->sysc_fields = &omap_hwmod_sysc_type3;
> + break;
> + case 1:
> + default:
> + sysc->sysc_fields = &omap_hwmod_sysc_type1;
> + }
> + class->sysc = sysc;
> + oh->class = class;
> +
> + return 0;
> +}
> +
> /**
> * _init - initialize internal data for the hwmod @oh
> * @oh: struct omap_hwmod *
> @@ -2449,6 +2559,12 @@ static int __init _init(struct omap_hwmod *oh, void
> *data)
> else if (np && index)
> pr_warn("omap_hwmod: %s using broken dt data from %s\n",
> oh->name, np->name);
> +
> + if (np) {
> + r = omap_hwmod_init_sysc(np, oh, 0);
this won't handle any binding which lists more than one hwmod on its
ti,hwmods property.
--
balbi
signature
Re: [RFC/PATCH 4/7] arm: omap: device: add support for generating sysconfig data from DT
Hi,
adding linux-omap back
On Wed, Dec 10, 2014 at 04:19:06PM +0530, Lokesh Vutla wrote:
> > + switch (prop) {
> > + case 2:
> > + sysc->sysc_fields = &omap_hwmod_sysc_type2;
> > + break;
> > + case 3:
> > + sysc->sysc_fields = &omap_hwmod_sysc_type3;
> > + break;
> > + case 1:
> > + default:
> > + sysc->sysc_fields = &omap_hwmod_sysc_type1;
> > + }
> Missed hooking the class to oh?
> class->sysc = sysc;
yeah, I'll fix that.
--
balbi
signature.asc
Description: Digital signature
Re: __hci_cmd_sync() not suitable for nokia h4p
Hi!
> > The TODO file says:
> >
> > # > +
> > # > + skb_queue_tail(&info->txq, fw_skb);
> > # > + spin_lock_irqsave(&info->lock, flags);
> > # > + hci_h4p_outb(info, UART_IER, hci_h4p_inb(info, UART_IER) |
> > # > + UART_IER_THRI);
> > # > + spin_unlock_irqrestore(&info->lock, flags);
> > # > +}
> > #
> > # and as I explained before, this crazy can not continue. Bluetooth drivers
> > can provide a
> > # +hdev->setup callback for loading firmware and doing other setup details.
> > You can just
> > # +bring up the HCI transport. We are providing __hci_cmd_sync for easy
> > loading of the
> > # +firmware. Especially if the firmware just consists of HCI commands.
> > Which is clearly the
> > # +case with the Nokia firmware files.
> >
> > ...so I take it you (and thus TODO) were wrong and __hci_cmd_sync is
> > not suitable after all?
>
> __hci_cmd_sync is to be used in hdev->setup where you load the firmware.
> However when hdev->setup is run, we expect that the HCI transport is fully up
> and running and that the driver takes care of the transport. That is done via
> hdev->send and hci_recv_frame.
>
h4p changes uart speed again after load of the firmware, but I guess
that's ok.
> > But I don't understand what you want me to do at this point. I guess
> > skb_queue_tail+hci_h4p_outb should be moved to a helper function
> > (that's easy), and I already moved initialization to hci_setup().
> >
> > nokia_core.c uses test_bit(HCI_RUNNING, &info->hdev->flags) to tell
> > between initialization and data traffic, but I guess that's fine?
>
> I have no idea on how much more I can explain this. There should be code in
> the driver that handles the HCI transport. That means init of the transport
> and sending and receiving HCI frames. And then there is the piece to load the
> firmware etc. These are two independent things.
>
Ok, it looks like __hci_cmd_sync() is indeed good match for the
firmware load.
>
> What needs to be done is the bring up of the device including the proper UART
> settings and speed and then just run the firmware downloads. All firmware
> files on the Nokia devices where just HCI commands with vendor specific
> details. Some from CSR, some from Broadcom and some from TI. You can actually
> decode them if you really want to. Shouldn't be that hard.
>
Speed changes at the end of firmware load, but I guess that's detail?
Anyway, patch would look like this.
diff --git a/drivers/staging/nokia_h4p/nokia_core.c
b/drivers/staging/nokia_h4p/nokia_core.c
index 9ece2c8..5cdb86a 100644
--- a/drivers/staging/nokia_h4p/nokia_core.c
+++ b/drivers/staging/nokia_h4p/nokia_core.c
@@ -475,12 +475,6 @@ static inline void hci_h4p_recv_frame(struct hci_h4p_info
*info,
info->rx_state = WAIT_FOR_PKT_TYPE;
return;
}
-
- if (!test_bit(HCI_UP, &info->hdev->flags)) {
- BT_DBG("fw_event");
- hci_h4p_parse_fw_event(info, skb);
- return;
- }
}
hci_recv_frame(info->hdev, skb);
diff --git a/drivers/staging/nokia_h4p/nokia_fw-bcm.c
b/drivers/staging/nokia_h4p/nokia_fw-bcm.c
index 8066b21..89718d4 100644
--- a/drivers/staging/nokia_h4p/nokia_fw-bcm.c
+++ b/drivers/staging/nokia_h4p/nokia_fw-bcm.c
@@ -45,84 +45,17 @@ static int hci_h4p_bcm_set_bdaddr(struct hci_h4p_info *info,
return 0;
}
-void hci_h4p_bcm_parse_fw_event(struct hci_h4p_info *info, struct sk_buff *skb)
-{
- struct sk_buff *fw_skb;
- int err;
- unsigned long flags;
-
- if (skb->data[5] != 0x00) {
- dev_err(info->dev, "Firmware sending command failed 0x%.2x\n",
- skb->data[5]);
- info->fw_error = -EPROTO;
- }
-
- kfree_skb(skb);
-
- fw_skb = skb_dequeue(info->fw_q);
- if (fw_skb == NULL || info->fw_error) {
- complete(&info->fw_completion);
- return;
- }
-
- if (fw_skb->data[1] == 0x01 && fw_skb->data[2] == 0xfc &&
- fw_skb->len >= 10) {
- BT_DBG("Setting bluetooth address");
- err = hci_h4p_bcm_set_bdaddr(info, fw_skb);
- if (err < 0) {
- kfree_skb(fw_skb);
- info->fw_error = err;
- complete(&info->fw_completion);
- return;
- }
- }
-
- hci_h4p_simple_send_frame(info, fw_skb);
-}
-
-
int hci_h4p_bcm_send_fw(struct hci_h4p_info *info,
struct sk_buff_head *fw_queue)
{
- struct sk_buff *skb;
- unsigned long flags, time;
+ unsigned long time;
info->fw_error = 0;
- BT_DBG("Sending firmware");
+ printk("Sending firmware (not really)\n");
time = jiffies;
-
- info->fw_q = fw_queue;
- skb = skb_dequeue(fw_queue);
- if (!skb)
-
Re: [RFC/PATCH 2/7] arm: omap: devicetree: add new properties for OMAP devices
Hi Felipe,
On Wednesday 10 December 2014 03:57 AM, Felipe Balbi wrote:
> In order to get rid of some more hwmod data, we
> introduce a few extra properties to OMAP DT
> data in order to be able to pass the needed
> information through DT.
>
> Signed-off-by: Felipe Balbi
> ---
> Documentation/devicetree/bindings/arm/omap/omap.txt | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index 4f6a82c..c6b9515 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -23,6 +23,13 @@ Optional properties:
>during suspend.
> - ti,no-reset-on-init: When present, the module should not be reset at init
> - ti,no-idle-on-init: When present, the module should not be idled at init
> +- ti,rev_offs: IP block revision register offset (defaults to 0)
> +- ti,sysc_offs: OCP_SYSCONFIG register offset (defaults to 0)
> +- ti,syss_offs: OCP_SYSSTATUS register offset (defaults to 0)
> +- ti,srst_udelay: Delay needed after a softreset in usecs (defaults to 0)
> +- ti,idlemodes: Slave and Master supported idling modes
> +- ti,clockact: default value of clock activity bits (defaults to 0)
> +- ti,sysc_type: OCP_SYSCONFIG type. Valid types are 1, 2 or 3 (defaults to 1)
Once if all the hwmod data comes to dt it will be very dufficult to see all the
data
together. Can we separate out hwmod class data like clocks data is separated
out into different node
or something of the sort like below?
ti, hwmod_class {
ti,class_name = <>;
ti,rev_offs = <>;
ti,sysc_offs = <>;
ti,syss_offs = <>;
ti,srst_udelay = <>;
ti,idlemodes = <>;
ti,clockact = <>;
ti,sysc_type = <>;
};
example:
counter32k: counter@44e86000 {
compatible =
"ti,am4372-counter32k","ti,omap-counter32k";
reg = <0x44e86000 0x40>;
ti,hwmods = "counter_32k";
ti,hwmod_class {
ti,class_name = "synctimer";
ti,idlemodes = <0x3>;
ti,sysc_flags = <0x20>;
ti,sysc_offs = <0x4>;
};
};
Thanks and regards,
Lokesh
>
> Example:
>
>
--
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: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
Hello,
On 2014-12-09 17:57, Nishanth Menon wrote:
On 10:13-20141205, Nishanth Menon wrote:
On 12/05/2014 10:10 AM, Nishanth Menon wrote:
next-20141204 fails to boot, but next-20141203 boots fine with
omap2plus_defconfig.
Panda-ES(4460):
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt
Panda(4430):
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-vanilla.txt
at the point of hang (JTAG):
pandaboard-es:
cpu0: http://slexy.org/view/s2eIFqkRd5
cpu1: http://slexy.org/view/s2Tysb6gpL
Case #1:
Disabling CPUIDLE allows boot to proceed. there does not seem to have
been any change in drivers/cpuidle and arch/arm/mach-omap2 w.r.t this.
Case #2: Reverting the following allows boot.
From next-20141204
10df7d5 ARM: 8211/1: l2c: Add support for overriding prefetch settings
revert this -> boot still fails
d42ced0 ARM: 8210/1: l2c: Get outer cache .write_sec callback from
mach_desc only if not NULL
revert this -> boot still fails
46b9af8 ARM: 8209/1: l2c: Add interface to ask hypervisor to configure L2C
revert this -> boot still fails
c94e325 ARM: 8208/1: l2c: Refactor the driver to use commit-like
revert this -> boot passed (first bad commit).
+ linux-samsung soc and updated Thomaz's mail ID (gmail now).
Spend a few mins trying to track this down and it does look like commit
c94e325 does a kmemdup for the data as part of l2x0_of_init->__l2c_init
This fails since the invocation is in early_init. doing it a bit later
as the following hack makes it work
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 608079a..0bc6bd9 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -170,12 +170,19 @@ static const char *const omap4_boards_compat[]
__initconst = {
NULL,
};
+
+static void tmp_init_irq(void)
+{
+ omap_l2_cache_init();
+ omap_gic_of_init();
+}
+
DT_MACHINE_START(OMAP4_DT, "Generic OMAP4 (Flattened Device Tree)")
.reserve= omap_reserve,
.smp= smp_ops(omap4_smp_ops),
.map_io = omap4_map_io,
.init_early = omap4430_init_early,
- .init_irq = omap_gic_of_init,
+ .init_irq = tmp_init_irq,
.init_machine = omap_generic_init,
.init_late = omap4430_init_late,
.init_time = omap4_local_timer_init,
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 03cbb16..f97847d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -627,7 +627,6 @@ void __init omap4430_init_early(void)
omap44xx_clockdomains_init();
omap44xx_hwmod_init();
omap_hwmod_init_postsetup();
- omap_l2_cache_init();
omap_clk_soc_init = omap4xxx_dt_clk_init;
}
Please note that am43xx_init_early() also calls omap_l2_cache_init(),
so similar fix is needed for "Generic AM43 (Flattened Device Tree)"
machines.
I've briefly looked how the initialization is done on various omap
platforms, but I don't see the good generic place for omap_l2_cache_init().
IMHO the best solution will be to completely switch to generic/common l2c
initialization and provide ".l2c_aux_val" and ".l2c_aux_mask" in machine
descriptor. For the time being something like proposed above can be used.
I assume that now it won't be possible to get l2c patches back to -next,
so I will resend them (again...) with the omap related fix.
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index e5948c5..0ca90db 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -848,8 +848,11 @@ static int __init __l2c_init(const struct l2c_init_data
*data,
* context from callers can access the structure.
*/
l2x0_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!l2x0_data)
+ if (!l2x0_data) {
+ pr_err("%s no mem %d\n", __func__, sizeof(*data));
+ dump_stack();
return -ENOMEM;
+ }
/*
* Sanity check the aux values. aux_mask is the bits we preserve
@@ -1647,6 +1650,7 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
struct device_node *np;
struct resource res;
u32 cache_id, old_aux;
+ int r;
np = of_find_matching_node(NULL, l2x0_ids);
if (!np)
@@ -1693,6 +1697,8 @@ int __init l2x0_of_init(u32 aux_val, u32 aux_mask)
else
cache_id = readl_relaxed(l2x0_base + L2X0_CACHE_ID);
- return __l2c_init(data, aux_val, aux_mask, cache_id);
+ r = __l2c_init(data, aux_val, aux_mask, cache_id);
+ pr_err("%s: %d\n", __func__, r);
+ return r;
}
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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://vg
