* [PATCH 0/2] Replace /include/ (dtc) with #include
From: Rob Herring @ 2014-01-27 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127163111.GA8358@arm.com>
On Mon, Jan 27, 2014 at 10:31 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Mon, Jan 27, 2014 at 11:07:04AM +0000, Pankaj Dubey wrote:
>> On 01/10/2014 07:16 PM, Pankaj Dubey wrote:
>> > Replace /include/ (dtc) with #include (C pre-processor) for all ARM64
>> > based SoC dts files.
>> >
>> > Pankaj Dubey (2):
>> > arm64: dts: use #include for all AppliedMicro device tree files
>> > arm64: dts: use #include for all ARM fast model device tree file
>> >
>> > arch/arm64/boot/dts/apm-mustang.dts | 2 +-
>> > arch/arm64/boot/dts/rtsm_ve-aemv8a.dts | 2 +-
>> > 2 files changed, 2 insertions(+), 2 deletions(-)
>> >
>> Gentle ping.
>
> It would be good to include some rationale behind this change and I'm
> waiting for the DT guys to ack it.
Change this when you actually need it.
Rob
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Uwe Kleine-König @ 2014-01-27 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390845177-2626-1-git-send-email-lauraa@codeaurora.org>
On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
> The dma_mask for a device structure is a pointer. This pointer
> needs to be set up before the dma mask can actually be set. Most
> frameworks in the kernel take care of setting this up properly but
> platform devices that don't follow a regular bus structure may not
> ever have this set. As a result, checks such as dma_capable will
> always return false on a raw platform device and dma_set_mask will
> always return -EIO. Fix this by adding a dma_mask in the
> platform_device archdata and setting it to be the dma_mask. Devices
> used in other frameworks can change this as needed.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Suggested-by: Kumar Gala <galak@codeaurora.org>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Hello,
there is another non-platform dependant approach available, that might
be worth to evaluate:
http://mid.gmane.org/1390817152-30898-1-git-send-email-ydroneaud at opteya.com
> ---
> arch/arm64/include/asm/device.h | 1 +
> arch/arm64/kernel/setup.c | 7 +++++++
> 2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
> index cf98b36..209d40c 100644
> --- a/arch/arm64/include/asm/device.h
> +++ b/arch/arm64/include/asm/device.h
> @@ -24,6 +24,7 @@ struct dev_archdata {
> };
>
> struct pdev_archdata {
> + u64 dma_mask;
> };
>
> #endif
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index bd9bbd0..f164347 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -41,6 +41,7 @@
> #include <linux/memblock.h>
> #include <linux/of_fdt.h>
> #include <linux/of_platform.h>
> +#include <linux/dma-mapping.h>
>
> #include <asm/cputype.h>
> #include <asm/elf.h>
> @@ -337,3 +338,9 @@ const struct seq_operations cpuinfo_op = {
> .stop = c_stop,
> .show = c_show
> };
> +
> +void arch_setup_pdev_archdata(struct platform_device *pdev)
> +{
> + pdev->archdata.dma_mask = DMA_BIT_MASK(32);
> + pdev->dev.dma_mask = &pdev->archdata.dma_mask;
> +}
Is it save to assume a default of DMA_BIT_MASK(32)?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Sebastian Hesselbarth @ 2014-01-27 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127153908.4f6f46c2@skate>
On 01/27/14 15:39, Thomas Petazzoni wrote:
> On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
>> This patch set fixes clk init order that went upside-down with
>> v3.14. I haven't really investigated what caused this, but I assume
>> it is related with DT node reordering by addresses.
>>
>> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
>> registered before core clocks driver. Unfortunately, we cannot
>> return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
>> init order for our drivers is always core clocks before clock gating,
>> we maintain init order ourselves by hooking CLK_OF_DECLARE to one
>> init function that will register core clocks before clock gating
>> driver.
>>
>> This patch is based on pre-v3.14-rc1 mainline and should go in as
>> fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
>> I suggest Jason picks it up as a topic branch.
>
> I'm not sure I really like the solution you're proposing here. I'd very
> much prefer to keep one CLK_OF_DECLARE() per clock type, associated to
> one function registering only this clock type.
Have you ever had a look at e.g. clk-imx28.c? Not that I really like
the approach, but it is common practice to do so.
> Instead, shouldn't the clock framework be improved to *not* register a
> clock until its parent have been registered? If the DT you have the
> gatable clocks that depend on the core clocks, then the gatable clocks
> should not be registered if the core clocks have not yet been
> registered.
>
> Do you think this is possible? Am I missing something here?
As I said, clk_of_init does not care about return values from the
clock init functions. Without it, it cannot decide if a clock
driver failed horribly, failed because of missing dependencies, or
successfully installed all clocks. Also, it is early stuff and I guess
clk_of_init will have to build its own "defered_list" and loop over
until done.
BTW, this is a fix not an improvement. We should find an acceptable
solution soon. But I am still open for suggestions, too.
Sebastian
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-27 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127.144815.1048814583962628826.apm@brigitte.kvy.fi>
On Mon, Jan 27, 2014 at 12:48:15PM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > That's why I defined the worst case. How did you implemented it in your
> > idle drivers ? That would help generalize it, after all these bindings
> > are there to simplify drivers upstreaming, feedback welcome.
>
> Currently we do not handle this well downstream either. The problem
> with worst case is that the absolute worst case can be really bad and
> probability of it might be very low. Sorry - no ready answer :-)
Point taken, but these bindings still get us to a point that is much
better than today situation. After all, if the worst case can happen
either we design for worst case or we update parameters at runtime in
the kernel (which is not happening as of now) according to a notification
mechanism.
It is certainly worth investigating, probably we can define OPPs as
generic (ie not tied to the CPU), as performance point or system
operating points. I will think about this.
In the meantime if you have further pieces of feedback please keep them
coming.
Thanks,
Lorenzo
^ permalink raw reply
* [RESEND][RFC PATCH 2/2] arm: Get rid of meminfo
From: Laura Abbott @ 2014-01-27 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E13ECC.3070203@ti.com>
Hi, Thanks for the review
On 1/23/2014 8:09 AM, Grygorii Strashko wrote:
...
>>
>> @@ -692,6 +685,12 @@ int __init arm_add_memory(u64 start, u64 size)
>> * Pick out the memory size. We look for mem=size at start,
>> * where start and size are "size[KkMm]"
>> */
>> +
>> +/*
>> + * XXX this is busted when just using memblock. Need to add memblock
>> + * hook to reset.
>> + */
>> +
>> static int __init early_mem(char *p)
>> {
>> static int usermem __initdata = 0;
>> @@ -706,7 +705,6 @@ static int __init early_mem(char *p)
>> */
>> if (usermem == 0) {
>> usermem = 1;
>> - meminfo.nr_banks = 0;
>> }
>
> The below code might work here:
> memblock_remove(memblock_start_of_DRAM(),
> memblock_end_of_DRAM() - memblock_start_of_DRAM());
>
That removes the memory but if we've already reserved any memory then
the memblock state will be inconsistent. I guess we can assume this is
early enough where no reserves will have taken place.
>>
>> start = PHYS_OFFSET;
>> @@ -851,13 +849,6 @@ static void __init reserve_crashkernel(void)
>> static inline void reserve_crashkernel(void) {}
>> #endif /* CONFIG_KEXEC */
>>
>
> [...]
>
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index e0e3968..c6ea491 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -81,24 +81,21 @@ __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>> * initialization functions, as well as show_mem() for the skipping
>> * of holes in the memory map. It is populated by arm_add_memory().
>> */
>> -struct meminfo meminfo;
>> -
>> void show_mem(unsigned int filter)
>> {
>> int free = 0, total = 0, reserved = 0;
>> - int shared = 0, cached = 0, slab = 0, i;
>> - struct meminfo * mi = &meminfo;
>> + int shared = 0, cached = 0, slab = 0;
>> + struct memblock_region *reg;
>>
>> printk("Mem-info:\n");
>> show_free_areas(filter);
>>
>> - for_each_bank (i, mi) {
>> - struct membank *bank = &mi->bank[i];
>> + for_each_memblock (memory, reg) {
>> unsigned int pfn1, pfn2;
>> struct page *page, *end;
>>
>> - pfn1 = bank_pfn_start(bank);
>> - pfn2 = bank_pfn_end(bank);
>> + pfn1 = memblock_region_memory_base_pfn(reg);
>> + pfn2 = memblock_region_memory_end_pfn(reg);
>>
>> page = pfn_to_page(pfn1);
>> end = pfn_to_page(pfn2 - 1) + 1;
>> @@ -130,16 +127,9 @@ void show_mem(unsigned int filter)
>> static void __init find_limits(unsigned long *min, unsigned long
>> *max_low,
>> unsigned long *max_high)
>> {
>> - struct meminfo *mi = &meminfo;
>> - int i;
>> -
>> - /* This assumes the meminfo array is properly sorted */
>> - *min = bank_pfn_start(&mi->bank[0]);
>> - for_each_bank (i, mi)
>> - if (mi->bank[i].highmem)
>> - break;
>> - *max_low = bank_pfn_end(&mi->bank[i - 1]);
>> - *max_high = bank_pfn_end(&mi->bank[mi->nr_banks - 1]);
>> + *max_low = PFN_DOWN(memblock_get_current_limit());
>> + *min = PFN_UP(memblock_start_of_DRAM());
>> + *max_high = PFN_DOWN(memblock_end_of_DRAM());
>
> Just to notify. Above values may have different values after your
> change, because of usage arm_memblock_steal(). Is it ok?
>
Yes, I think so. The memory from arm_memblock_steal isn't really in the
system anyway so it seems incorrect to be treating it as such.
>> }
>>
>> static void __init arm_bootmem_init(unsigned long start_pfn,
>> @@ -327,14 +317,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t
>> size, phys_addr_t align)
>> return phys;
>> }
>>
>> -void __init arm_memblock_init(struct meminfo *mi,
>> - const struct machine_desc *mdesc)
>> +void __init arm_memblock_init(const struct machine_desc *mdesc)
>> {
>> - int i;
>> -
>> - for (i = 0; i < mi->nr_banks; i++)
>> - memblock_add(mi->bank[i].start, mi->bank[i].size);
>> -
>> /* Register the kernel text, kernel data and initrd with
>> memblock. */
>> #ifdef CONFIG_XIP_KERNEL
>> memblock_reserve(__pa(_sdata), _end - _sdata);
>> @@ -466,48 +450,47 @@ free_memmap(unsigned long start_pfn, unsigned
>> long end_pfn)
>> /*
>> * The mem_map array can get very big. Free the unused area of the
>> memory map.
>> */
>> -static void __init free_unused_memmap(struct meminfo *mi)
>> +static void __init free_unused_memmap(void)
>> {
>> - unsigned long bank_start, prev_bank_end = 0;
>> - unsigned int i;
>> + unsigned long start, prev_end = 0;
>> + struct memblock_region *reg;
>>
>> /*
>> * This relies on each bank being in address order.
>> * The banks are sorted previously in bootmem_init().
>> */
>> - for_each_bank(i, mi) {
>> - struct membank *bank = &mi->bank[i];
>> -
>> - bank_start = bank_pfn_start(bank);
>> + for_each_memblock(memory, reg) {
>> + start = __phys_to_pfn(reg->base);
>>
>> #ifdef CONFIG_SPARSEMEM
>> /*
>> * Take care not to free memmap entries that don't exist
>> * due to SPARSEMEM sections which aren't present.
>> */
>> - bank_start = min(bank_start,
>> - ALIGN(prev_bank_end, PAGES_PER_SECTION));
>> + start = min(start,
>> + ALIGN(prev_end, PAGES_PER_SECTION));
>> #else
>> /*
>> * Align down here since the VM subsystem insists that the
>> * memmap entries are valid from the bank start aligned to
>> * MAX_ORDER_NR_PAGES.
>> */
>> - bank_start = round_down(bank_start, MAX_ORDER_NR_PAGES);
>> + start = round_down(start, MAX_ORDER_NR_PAGES);
>> #endif
>> /*
>> * If we had a previous bank, and there is a space
>> * between the current bank and the previous, free it.
>> */
>> - if (prev_bank_end && prev_bank_end < bank_start)
>> - free_memmap(prev_bank_end, bank_start);
>> + if (prev_end && prev_end < start)
>> + free_memmap(prev_end, start);
>>
>> /*
>> * Align up here since the VM subsystem insists that the
>> * memmap entries are valid from the bank end aligned to
>> * MAX_ORDER_NR_PAGES.
>> */
>> - prev_bank_end = ALIGN(bank_pfn_end(bank), MAX_ORDER_NR_PAGES);
>> + prev_end = ALIGN(start + __phys_to_pfn(reg->size),
>> + MAX_ORDER_NR_PAGES);
>> }
>>
>> #ifdef CONFIG_SPARSEMEM
>> @@ -589,7 +572,7 @@ void __init mem_init(void)
>> max_mapnr = pfn_to_page(max_pfn + PHYS_PFN_OFFSET) - mem_map;
>>
>> /* this will put all unused low memory onto the freelists */
>> - free_unused_memmap(&meminfo);
>> + free_unused_memmap();
>> free_all_bootmem();
>>
>> #ifdef CONFIG_SA1111
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index 4f08c13..394701c 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -1043,77 +1043,54 @@ early_param("vmalloc", early_vmalloc);
>>
>> phys_addr_t arm_lowmem_limit __initdata = 0;
>>
>> +static void remove_memblock(phys_addr_t base, phys_addr_t size)
>> +{
>> + memblock_reserve(base, size);
>> + memblock_free(base, size);
>> + memblock_remove(base, size);
>> +}
>
> I think it'll be ok to use just memblock_remove(base, size); below.
>
This was my concern about reserved but I think you are correct that we
should be able to just remove without worrying about reserved areas.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 05/11] pinctrl: mvebu: fix misdesigned resource allocation
From: Sebastian Hesselbarth @ 2014-01-27 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127154532.4bc3eeef@skate>
On 01/27/14 15:45, Thomas Petazzoni wrote:
> On Sat, 25 Jan 2014 19:34:10 +0100, Sebastian Hesselbarth wrote:
>> Allocating the pinctrl resource in common pinctrl-mvebu was a misdesign,
>> as it does not allow SoC specific parts to access the allocated resource.
>> This moves resource allocation from mvebu_pinctrl_probe to SoC specific
>> _probe functions and passes the base address to common pinctrl driver
>> instead.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>
> I definitely agree with that: I had the same problem several months ago
> when I started doing the pinctrl driver for Orion5x, which has a
> non-linear MPP register set.
>
> However, I'd like this to go a little bit further if possible. See
> below.
Agreed.
>> - return mvebu_pinctrl_probe(pdev);
>> + return mvebu_pinctrl_probe(pdev, base);
>
> I think there is no need to pass "base" to mvebu_pinctrl_probe(). The
> only reason we have this is because the base gets stored in the
> mvebu_pinctrl structure so that the mvebu_common_mpp_get() and
> mvebu_common_mpp_set() functions that are the default behavior
> for mvebu_pinconf_group_get() and mvebu_pinconf_group_set() work
> properly.
>
> Shouldn't we turn these functions mvebu_common_mpp_get() and
> mvebu_common_mpp_set() into helper functions, accessible from the
> per-SoC pinctrl drivers, so that they can easily implement their
> ->mpp_get() and ->mpp_set() callbacks?
Sounds reasonable to do so. I have a look at removing the base address
from common.c completely.
Sebastian
> This way, the "base" thing is completely owned by the per-SoC driver,
> which would be more logical I believe.
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Jason Cooper @ 2014-01-27 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6A3B2.6060301@gmail.com>
On Mon, Jan 27, 2014 at 07:21:38PM +0100, Sebastian Hesselbarth wrote:
> On 01/27/14 15:39, Thomas Petazzoni wrote:
> >On Sat, 25 Jan 2014 19:19:06 +0100, Sebastian Hesselbarth wrote:
> >>This patch set fixes clk init order that went upside-down with
> >>v3.14. I haven't really investigated what caused this, but I assume
> >>it is related with DT node reordering by addresses.
> >>
> >>Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
> >>registered before core clocks driver. Unfortunately, we cannot
> >>return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
> >>init order for our drivers is always core clocks before clock gating,
> >>we maintain init order ourselves by hooking CLK_OF_DECLARE to one
> >>init function that will register core clocks before clock gating
> >>driver.
> >>
> >>This patch is based on pre-v3.14-rc1 mainline and should go in as
> >>fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
> >>I suggest Jason picks it up as a topic branch.
> >
> >I'm not sure I really like the solution you're proposing here. I'd very
> >much prefer to keep one CLK_OF_DECLARE() per clock type, associated to
> >one function registering only this clock type.
>
> Have you ever had a look at e.g. clk-imx28.c? Not that I really like
> the approach, but it is common practice to do so.
>
> >Instead, shouldn't the clock framework be improved to *not* register a
> >clock until its parent have been registered? If the DT you have the
> >gatable clocks that depend on the core clocks, then the gatable clocks
> >should not be registered if the core clocks have not yet been
> >registered.
> >
> >Do you think this is possible? Am I missing something here?
>
> As I said, clk_of_init does not care about return values from the
> clock init functions. Without it, it cannot decide if a clock
> driver failed horribly, failed because of missing dependencies, or
> successfully installed all clocks. Also, it is early stuff and I guess
> clk_of_init will have to build its own "defered_list" and loop over
> until done.
>
> BTW, this is a fix not an improvement. We should find an acceptable
> solution soon. But I am still open for suggestions, too.
fyi: I suspect this may be the problem currently experienced by Kevin on
mirabox in the boot farm. He sees it on current master. Adding him to
the Cc.
thx,
Jason.
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Arnaud Ebalard @ 2014-01-27 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140126143019.09d0b9e0@skate>
Hi Thomas and Sarah,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> On Thu, 23 Jan 2014 09:24:41 +0100, Arnaud Ebalard wrote:
>
>> The various Armada-based devices I have are NAS which do not have PCIe
>> slots to plug additional devices (everything is soldered). I don't know
>> which device Thomas used for its tests. Just in case, I also added Willy
>> in CC: who have various boards and may also have done more test with
>> additional PCIe devices and CONFIG_PCI_MSI enabled on 3.13 kernel.
>
> The device I've used to test MSI is a e1000e PCIe Intel network card.
> It uses one MSI interrupt, so admittedly, the MSI testing is quite
> limited for now.
I had a second thought this WE about a previous question from Sarah: my
platforms do not have a PCIe extension slots to test other devices but
the RN102 does have an additional device connected on the PCIe bus: a
Marvell 88SE9170 SATA Controller. I have put below the output of lspci
-vvv (on a 3.13.0-rc8 kernel w/ CONFIG_PCI_MSI enabled) in case you can
spot something obviously wrong in it:
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00010000-00010fff
Memory behind bridge: e0000000-e00fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: e0100000-e01fffff
Prefetchable memory behind bridge: 00000000-000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9170 (rev 12) (prog-if 01 [AHCI 1.0])
Subsystem: Marvell Technology Group Ltd. Device 9170
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 105
Region 0: I/O ports at 10010 [size=8]
Region 1: I/O ports at 10020 [size=4]
Region 2: I/O ports at 10018 [size=8]
Region 3: I/O ports at 10024 [size=4]
Region 4: I/O ports at 10000 [size=16]
Region 5: Memory at e0010000 (32-bit, non-prefetchable) [size=512]
Expansion ROM@e0000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: d0020a04 Data: 0f10
Capabilities: [70] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Kernel driver in use: ahci
02:00.0 USB controller: Fresco Logic FL1009 USB 3.0 Host Controller (rev 02) (prog-if 30 [XHCI])
Subsystem: Fresco Logic Device 0000
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 104
Region 0: Memory at e0100000 (64-bit, non-prefetchable) [size=64K]
Region 2: Memory at e0110000 (64-bit, non-prefetchable) [size=4K]
Region 4: Memory@e0111000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable+ Count=8 Masked-
Vector table: BAR=2 offset=00000000
PBA: BAR=4 offset=00000000
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Kernel driver in use: xhci_hcd
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Laura Abbott @ 2014-01-27 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127181836.GH26766@pengutronix.de>
On 1/27/2014 10:18 AM, Uwe Kleine-K?nig wrote:
> On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
>> The dma_mask for a device structure is a pointer. This pointer
>> needs to be set up before the dma mask can actually be set. Most
>> frameworks in the kernel take care of setting this up properly but
>> platform devices that don't follow a regular bus structure may not
>> ever have this set. As a result, checks such as dma_capable will
>> always return false on a raw platform device and dma_set_mask will
>> always return -EIO. Fix this by adding a dma_mask in the
>> platform_device archdata and setting it to be the dma_mask. Devices
>> used in other frameworks can change this as needed.
>>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Suggested-by: Kumar Gala <galak@codeaurora.org>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> Hello,
>
> there is another non-platform dependant approach available, that might
> be worth to evaluate:
>
> http://mid.gmane.org/1390817152-30898-1-git-send-email-ydroneaud at opteya.com
>
That covers dynamically allocated devices but it doesn't look like it
covers devices setup with just platform_device_register like
arch_setup_pdev_archdata does.
>> ---
>> arch/arm64/include/asm/device.h | 1 +
>> arch/arm64/kernel/setup.c | 7 +++++++
>> 2 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
>> index cf98b36..209d40c 100644
>> --- a/arch/arm64/include/asm/device.h
>> +++ b/arch/arm64/include/asm/device.h
>> @@ -24,6 +24,7 @@ struct dev_archdata {
>> };
>>
>> struct pdev_archdata {
>> + u64 dma_mask;
>> };
>>
>> #endif
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index bd9bbd0..f164347 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -41,6 +41,7 @@
>> #include <linux/memblock.h>
>> #include <linux/of_fdt.h>
>> #include <linux/of_platform.h>
>> +#include <linux/dma-mapping.h>
>>
>> #include <asm/cputype.h>
>> #include <asm/elf.h>
>> @@ -337,3 +338,9 @@ const struct seq_operations cpuinfo_op = {
>> .stop = c_stop,
>> .show = c_show
>> };
>> +
>> +void arch_setup_pdev_archdata(struct platform_device *pdev)
>> +{
>> + pdev->archdata.dma_mask = DMA_BIT_MASK(32);
>> + pdev->dev.dma_mask = &pdev->archdata.dma_mask;
>> +}
> Is it save to assume a default of DMA_BIT_MASK(32)?
>
This seemed like a reasonable default and matches what powerpc does. Any
device who wants to really guarantee a DMA mask should be setting the
dma mask explicitly and not relying on a default.
> Best regards
> Uwe
>
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH RESEND TAKE 3] clk: si5351: remove variant from platform_data
From: Mike Turquette @ 2014-01-27 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390682911-9022-1-git-send-email-sebastian.hesselbarth@gmail.com>
Quoting Sebastian Hesselbarth (2014-01-25 12:48:31)
> Commit 9807362bfe1748d9bb48eecb9261f1b1aaafea1c
> "clk: si5351: declare all device IDs for module loading"
> removed the common i2c_device_id and introduced new ones for each variant
> of the clock generator. Instead of exploiting that information in the driver,
> it still depends on platform_data passing the chips .variant.
>
> This removes the now redundant .variant from the platform_data and puts it in
> i2c_device_id's .driver_data instead.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Mike,
>
> this is the patch I mentioned during ARM summit ;). Still applies to
> pre-v3.14-rc1 cleanly. Maybe it is time to take it now?
Hi Sebastian,
You're right, I overlooked this one. I've taken it in now.
Regards,
Mike
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/clk/clk-si5351.c | 28 ++++++++++++----------------
> drivers/clk/clk-si5351.h | 14 ++++++++++++++
> include/linux/platform_data/si5351.h | 16 ----------------
> 3 files changed, 26 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index c50e837..b95aa09 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -1111,11 +1111,11 @@ static const struct of_device_id si5351_dt_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, si5351_dt_ids);
>
> -static int si5351_dt_parse(struct i2c_client *client)
> +static int si5351_dt_parse(struct i2c_client *client,
> + enum si5351_variant variant)
> {
> struct device_node *child, *np = client->dev.of_node;
> struct si5351_platform_data *pdata;
> - const struct of_device_id *match;
> struct property *prop;
> const __be32 *p;
> int num = 0;
> @@ -1124,15 +1124,10 @@ static int si5351_dt_parse(struct i2c_client *client)
> if (np == NULL)
> return 0;
>
> - match = of_match_node(si5351_dt_ids, np);
> - if (match == NULL)
> - return -EINVAL;
> -
> pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> if (!pdata)
> return -ENOMEM;
>
> - pdata->variant = (enum si5351_variant)match->data;
> pdata->clk_xtal = of_clk_get(np, 0);
> if (!IS_ERR(pdata->clk_xtal))
> clk_put(pdata->clk_xtal);
> @@ -1163,7 +1158,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
> break;
> case 1:
> - if (pdata->variant != SI5351_VARIANT_C) {
> + if (variant != SI5351_VARIANT_C) {
> dev_err(&client->dev,
> "invalid parent %d for pll %d\n",
> val, num);
> @@ -1187,7 +1182,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> }
>
> if (num >= 8 ||
> - (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
> + (variant == SI5351_VARIANT_A3 && num >= 3)) {
> dev_err(&client->dev, "invalid clkout %d\n", num);
> return -EINVAL;
> }
> @@ -1226,7 +1221,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> SI5351_CLKOUT_SRC_XTAL;
> break;
> case 3:
> - if (pdata->variant != SI5351_VARIANT_C) {
> + if (variant != SI5351_VARIANT_C) {
> dev_err(&client->dev,
> "invalid parent %d for clkout %d\n",
> val, num);
> @@ -1307,6 +1302,7 @@ static int si5351_dt_parse(struct i2c_client *client)
> static int si5351_i2c_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> + enum si5351_variant variant = (enum si5351_variant)id->driver_data;
> struct si5351_platform_data *pdata;
> struct si5351_driver_data *drvdata;
> struct clk_init_data init;
> @@ -1315,7 +1311,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
> u8 num_parents, num_clocks;
> int ret, n;
>
> - ret = si5351_dt_parse(client);
> + ret = si5351_dt_parse(client, variant);
> if (ret)
> return ret;
>
> @@ -1331,7 +1327,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
>
> i2c_set_clientdata(client, drvdata);
> drvdata->client = client;
> - drvdata->variant = pdata->variant;
> + drvdata->variant = variant;
> drvdata->pxtal = pdata->clk_xtal;
> drvdata->pclkin = pdata->clk_clkin;
>
> @@ -1568,10 +1564,10 @@ static int si5351_i2c_probe(struct i2c_client *client,
> }
>
> static const struct i2c_device_id si5351_i2c_ids[] = {
> - { "si5351a", 0 },
> - { "si5351a-msop", 0 },
> - { "si5351b", 0 },
> - { "si5351c", 0 },
> + { "si5351a", SI5351_VARIANT_A },
> + { "si5351a-msop", SI5351_VARIANT_A3 },
> + { "si5351b", SI5351_VARIANT_B },
> + { "si5351c", SI5351_VARIANT_C },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, si5351_i2c_ids);
> diff --git a/drivers/clk/clk-si5351.h b/drivers/clk/clk-si5351.h
> index c0dbf26..4d0746b 100644
> --- a/drivers/clk/clk-si5351.h
> +++ b/drivers/clk/clk-si5351.h
> @@ -153,4 +153,18 @@
> #define SI5351_XTAL_ENABLE (1<<6)
> #define SI5351_MULTISYNTH_ENABLE (1<<4)
>
> +/**
> + * enum si5351_variant - SiLabs Si5351 chip variant
> + * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> + * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> + * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> + * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> + */
> +enum si5351_variant {
> + SI5351_VARIANT_A = 1,
> + SI5351_VARIANT_A3 = 2,
> + SI5351_VARIANT_B = 3,
> + SI5351_VARIANT_C = 4,
> +};
> +
> #endif
> diff --git a/include/linux/platform_data/si5351.h b/include/linux/platform_data/si5351.h
> index 5433439..a947ab8 100644
> --- a/include/linux/platform_data/si5351.h
> +++ b/include/linux/platform_data/si5351.h
> @@ -8,20 +8,6 @@
> struct clk;
>
> /**
> - * enum si5351_variant - SiLabs Si5351 chip variant
> - * @SI5351_VARIANT_A: Si5351A (8 output clocks, XTAL input)
> - * @SI5351_VARIANT_A3: Si5351A MSOP10 (3 output clocks, XTAL input)
> - * @SI5351_VARIANT_B: Si5351B (8 output clocks, XTAL/VXCO input)
> - * @SI5351_VARIANT_C: Si5351C (8 output clocks, XTAL/CLKIN input)
> - */
> -enum si5351_variant {
> - SI5351_VARIANT_A = 1,
> - SI5351_VARIANT_A3 = 2,
> - SI5351_VARIANT_B = 3,
> - SI5351_VARIANT_C = 4,
> -};
> -
> -/**
> * enum si5351_pll_src - Si5351 pll clock source
> * @SI5351_PLL_SRC_DEFAULT: default, do not change eeprom config
> * @SI5351_PLL_SRC_XTAL: pll source clock is XTAL input
> @@ -115,14 +101,12 @@ struct si5351_clkout_config {
>
> /**
> * struct si5351_platform_data - Platform data for the Si5351 clock driver
> - * @variant: Si5351 chip variant
> * @clk_xtal: xtal input clock
> * @clk_clkin: clkin input clock
> * @pll_src: array of pll source clock setting
> * @clkout: array of clkout configuration
> */
> struct si5351_platform_data {
> - enum si5351_variant variant;
> struct clk *clk_xtal;
> struct clk *clk_clkin;
> enum si5351_pll_src pll_src[2];
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH] dt-bindings: qcom: Fix warning with duplicate dt define
From: Mike Turquette @ 2014-01-27 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390007119-4544-1-git-send-email-sboyd@codeaurora.org>
Quoting Stephen Boyd (2014-01-17 17:05:19)
> arch/arm/boot/dts/include/dt-bindings/clock/qcom,mmcc-msm8974.h:60:0:
> warning: "RBCPR_CLK_SRC" redefined
>
> Rename this to MMSS_RBCPR_CLK_SRC to avoid conflicts with the
> RBCPR clock in the gcc header.
>
> Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Thanks for the fix. I've pulled this into part 2 of my pull request.
Regards,
Mike
> ---
> include/dt-bindings/clock/qcom,mmcc-msm8974.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/clock/qcom,mmcc-msm8974.h b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> index 04d318d1187a..032ed87ef0f3 100644
> --- a/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> +++ b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> @@ -57,7 +57,7 @@
> #define EXTPCLK_CLK_SRC 40
> #define HDMI_CLK_SRC 41
> #define VSYNC_CLK_SRC 42
> -#define RBCPR_CLK_SRC 43
> +#define MMSS_RBCPR_CLK_SRC 43
> #define CAMSS_CCI_CCI_AHB_CLK 44
> #define CAMSS_CCI_CCI_CLK 45
> #define CAMSS_CSI0_AHB_CLK 46
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH v2 3/3] Binding: atmel-wm8904: add option to choose clock
From: Mark Brown @ 2014-01-27 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390805726-1841-4-git-send-email-voice.shen@atmel.com>
On Mon, Jan 27, 2014 at 02:55:26PM +0800, Bo Shen wrote:
> diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> index 8bbe50c..2d86e2b 100644
> --- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> +++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> @@ -33,6 +33,12 @@ Required properties:
>
> Optional properties:
> - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
> + - atmel,clk-from-rk-pin: bool property.
> + - When SSC works in slave mode, according to the hardware design, the
> + clock can get from TK pin, and also can get from RK pin. So, add
> + this parameter to choose where the clock from.
> + - By default the clock is from TK pin, if the clock from RK pin, this
> + property is needed.
Can this be made a property of the SSC device so that it's available for
all cards using it rather than just this one? That would also address
the issue with the way the configuration is passed to the controller
that Lars-Peter identified.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/89853ba3/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Russell King - ARM Linux @ 2014-01-27 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390845177-2626-1-git-send-email-lauraa@codeaurora.org>
On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
> The dma_mask for a device structure is a pointer. This pointer
> needs to be set up before the dma mask can actually be set. Most
> frameworks in the kernel take care of setting this up properly but
> platform devices that don't follow a regular bus structure may not
> ever have this set. As a result, checks such as dma_capable will
> always return false on a raw platform device and dma_set_mask will
> always return -EIO. Fix this by adding a dma_mask in the
> platform_device archdata and setting it to be the dma_mask. Devices
> used in other frameworks can change this as needed.
You shouldn't need to do this. I went through a lot of the drivers we
currently have, fixing them up in various manners. The basic rules
for this stuff are:
- It is the responsibility of the code creating the device to set a
reasonable default for the dma mask according to the bus and whether
DMA is supportable.
- It is the responsibility of the driver _always_ to make a call to
dma_set_mask() and/or dma_set_coherent_mask() according to the
driver's needs if the driver is going to be using DMA.
As a work-around for the buggy situation we have in the kernel with DT,
various buggy workarounds have been incorporated into drivers which
involve writing directly to the DMA masks, and other such games. None
of that is necessary when the dma_coerce_*() functions are used - but
these are a stop-gap until the DT code gets fixed.
The real answer here is to make DT conform to the first point above
and not add yet another different hack to the kernel.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jyri Sarha @ 2014-01-27 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127190641.273890c6@armhf>
On 01/27/2014 08:06 PM, Jean-Francois Moine wrote:
> On Mon, 27 Jan 2014 18:17:54 +0200
> Jyri Sarha <jsarha@ti.com> wrote:
>
>> Support for S16_LE could maybe be added if the tda998x specific codec
>> would fiddle with CTS_N predivider-setting (K select) according to the
>> used sample width. But it appears Cobox plays all the sample formats
>> fine without this change, so the question is if playing around with
>> CTS_N predivider would break already working support there (something to
>> be tested).
>
> Jyri,
>
> Setting
>
> cts_n = CTS_N_M(3) | CTS_N_K(1);
>
> instead of K(3) in the I2S sequence of tda998x_configure_audio() in the
> tda998x driver works fine for me with S16_LE and S24_LE.
>
> Does this solve your problem?
>
With that setting S16_LE works, but S32_LE does not. S24_LE does not
really work at all on BBB, or it works but because the 8 most
significant bits are zero the audio output is attenuated by 48 dB.
On the other hand S24_3LE does work, but then the problem is the clock
rate support. On BBB the McASP IP is the bit clock master and provides
the bit clock by simple divider from 24.576MHz oscillator. With 24 bit
samples neither 44100 or 48000Hz sample rate can be supported (on the
other hand 32kHz could be supported 24576000 % (24*2*32000) = 0).
The BBB HW price has squeezed so low that it can only implement the most
basic use cases.
I would suggest to leave the CTS_N_K to the current setting (3), unless
we can change the CTS_N_K on the fly according to the used sample format.
Best regards,
Jyri
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v3.13.x/v3.14-rc1
From: Jason Cooper @ 2014-01-27 19:34 UTC (permalink / raw)
To: linux-arm-kernel
Kevin,
Here's the pull we discussed earlier. Sorry my "send pull requests"
cron job failed me.
As usual, been in -next (a little long this time ;-) ), incremental from
tags/mvebu-fixes-3.13 to tags/mvebu-fixes-3.13-2 in the mvebu/fixes
branch.
thx,
Jason.
The following changes since commit f8b94beb7e6a374cb0de531b72377c49857b35ca:
i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible (2014-01-14 02:09:17 +0000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-3.13-2
for you to fetch changes up to 19e61d41404fe4094c2d54943dbf883d9bbca864:
ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP) (2014-01-21 00:55:47 +0000)
----------------------------------------------------------------
mvebu fixes for v3.13 (incremental #2)
- allow building and booting DT and non-DT plat-orion SoCs
- catch proper return value for kirkwood_pm_init()
- properly check return of of_iomap to solve boot hangs (mirabox, others)
- remove a compile warning on Armada 370 with non-SMP.
----------------------------------------------------------------
Arnaud Ebalard (1):
ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP)
Ezequiel Garcia (1):
ARM: kirkwood: kirkwood_pm_init() should return void
Gregory CLEMENT (1):
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed
Sebastian Hesselbarth (1):
ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER
arch/arm/mach-kirkwood/pm.c | 4 ++--
arch/arm/mach-mvebu/mvebu-soc-id.c | 2 +-
arch/arm/plat-orion/irq.c | 47 +++++++++++++++++++++++++++++++++++++
drivers/irqchip/irq-armada-370-xp.c | 4 ++--
4 files changed, 52 insertions(+), 5 deletions(-)
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jyri Sarha @ 2014-01-27 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E68A00.5030207@metafoo.de>
On 01/27/2014 06:32 PM, Lars-Peter Clausen wrote:
> On 01/27/2014 05:17 PM, Jyri Sarha wrote:
>> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>>> Hi,
>>>
>>> I think you should try to get this in sync with the work Jean-Francois is
>>> currently doing[1]. Having the HDMI transmitter register a CODEC device is
>>> definitely the right approach, compared to the rather 'interesting'
>>> constraints stuff you do in patch 4.
>>>
>>
>> Oh, Jean-Francois's patches are now out. I'll take those into use, but I am
>> afraid it still does not save me from the constraint stuff.
>>
>> The most complex piece of code comes from limited sample-rate availability,
>> which is coming Beaglebone-Black desing (available i2s master clock), not
>> from the HDMI encoder itself. It does not help with the stereo only
>> limitation either, because it comes from the one wire only audio data
>> connection on BBB.
>>
>> Support for S16_LE could maybe be added if the tda998x specific codec would
>> fiddle with CTS_N predivider-setting (K select) according to the used sample
>> width. But it appears Cobox plays all the sample formats fine without this
>> change, so the question is if playing around with CTS_N predivider would
>> break already working support there (something to be tested).
>
> The ASoC core will set the constraints for the audio format/rate to the
> intersection of what is supported by the CODEC and the CPU DAI. So if the
> limitation comes from the CPU DAI the constraints should be applied there
> and not in the machine driver. Similar if the tda998x only supports 32 bit
> samples it should advertise this and the compound card will only support 32
> bit samples.
>
Yes. I know. But these limitations come from the run time setup of the
audio serial bus and those details are not available to the cpu dai at
the register time.
If more of the McASP configuration data would be moved to DT, instead of
giving it in set_sysclk, set_fmt, etc. calls it would be possible for
the driver code produce more accurate constraints at register time.
However that would change McASP driver a lot and would possibly break
some of the legacy support.
Best regards,
Jyri
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Lars-Peter Clausen @ 2014-01-27 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6B613.9050400@ti.com>
On 01/27/2014 08:40 PM, Jyri Sarha wrote:
> On 01/27/2014 06:32 PM, Lars-Peter Clausen wrote:
>> On 01/27/2014 05:17 PM, Jyri Sarha wrote:
>>> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>>>> Hi,
>>>>
>>>> I think you should try to get this in sync with the work Jean-Francois is
>>>> currently doing[1]. Having the HDMI transmitter register a CODEC device is
>>>> definitely the right approach, compared to the rather 'interesting'
>>>> constraints stuff you do in patch 4.
>>>>
>>>
>>> Oh, Jean-Francois's patches are now out. I'll take those into use, but I am
>>> afraid it still does not save me from the constraint stuff.
>>>
>>> The most complex piece of code comes from limited sample-rate availability,
>>> which is coming Beaglebone-Black desing (available i2s master clock), not
>>> from the HDMI encoder itself. It does not help with the stereo only
>>> limitation either, because it comes from the one wire only audio data
>>> connection on BBB.
>>>
>>> Support for S16_LE could maybe be added if the tda998x specific codec would
>>> fiddle with CTS_N predivider-setting (K select) according to the used sample
>>> width. But it appears Cobox plays all the sample formats fine without this
>>> change, so the question is if playing around with CTS_N predivider would
>>> break already working support there (something to be tested).
>>
>> The ASoC core will set the constraints for the audio format/rate to the
>> intersection of what is supported by the CODEC and the CPU DAI. So if the
>> limitation comes from the CPU DAI the constraints should be applied there
>> and not in the machine driver. Similar if the tda998x only supports 32 bit
>> samples it should advertise this and the compound card will only support 32
>> bit samples.
>>
>
> Yes. I know. But these limitations come from the run time setup of the audio
> serial bus and those details are not available to the cpu dai at the register
> time.
>
> If more of the McASP configuration data would be moved to DT, instead of giving
> it in set_sysclk, set_fmt, etc. calls it would be possible for the driver code
> produce more accurate constraints at register time. However that would change
> McASP driver a lot and would possibly break some of the legacy support.
There is nothing wrong with setting the constraints based on the parameters
passed to set_sysclk or set_fmt, etc. In fact this is something that is often
done by drivers.
- Lars
^ permalink raw reply
* [PATCH] clk: Export more clk-provider functions
From: Mike Turquette @ 2014-01-27 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390016837-24837-1-git-send-email-sboyd@codeaurora.org>
Quoting Stephen Boyd (2014-01-17 19:47:17)
> Allow drivers to be compiled as modules by exporting more clock
> provider functions.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
I've taken this into part 2 of my pull request for 3.14.
Regards,
Mike
> ---
> drivers/clk/clk.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 0b27b543dacf..2e83cf643db0 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -547,16 +547,19 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
> {
> return !clk ? NULL : clk->hw;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_hw);
>
> u8 __clk_get_num_parents(struct clk *clk)
> {
> return !clk ? 0 : clk->num_parents;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_num_parents);
>
> struct clk *__clk_get_parent(struct clk *clk)
> {
> return !clk ? NULL : clk->parent;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_parent);
>
> struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
> {
> @@ -570,6 +573,7 @@ struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
> else
> return clk->parents[index];
> }
> +EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
>
> unsigned int __clk_get_enable_count(struct clk *clk)
> {
> @@ -601,6 +605,7 @@ unsigned long __clk_get_rate(struct clk *clk)
> out:
> return ret;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_rate);
>
> unsigned long __clk_get_flags(struct clk *clk)
> {
> @@ -649,6 +654,7 @@ bool __clk_is_enabled(struct clk *clk)
> out:
> return !!ret;
> }
> +EXPORT_SYMBOL_GPL(__clk_is_enabled);
>
> static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
> {
> @@ -740,6 +746,7 @@ out:
>
> return best;
> }
> +EXPORT_SYMBOL_GPL(__clk_mux_determine_rate);
>
> /*** clk api ***/
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH v4 07/24] drm/i2c: tda998x: set the video mode from the adjusted value
From: Russell King - ARM Linux @ 2014-01-27 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181443.5c079d76@armhf>
On Sat, Jan 25, 2014 at 06:14:43PM +0100, Jean-Francois Moine wrote:
> @@ -896,9 +897,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> * TDA19988 requires high-active sync at input stage,
> * so invert low-active sync provided by master encoder here
> */
> - if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NHSYNC)
> reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_H_TGL);
> - if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NVSYNC)
> reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_V_TGL);
>
> /*
It looks like this comment from Darren has not been addressed (or
commented on). Can you discuss this with Darren and come to some sort
of solution please, otherwise applying this patch set is going to cause
a regression. Thanks.
=8<
Using the adj_mode->flags breaks a workaround I had done on BeagleBone Black
(tilcdc + tda998x) to resolve an issue with out of spec syncs from the
tlcdc. I invert the HSYNC in adj_mode->flags but don't want the tda998x to
really know that I am doing that so I use adj_mode in the tilcdc driver, and
mode here in the tda998x driver. The theory being adj_mode contains whatever
workarounds I need to do for the driving device and mode has the pristine
values that I want to send to the monitor. I would need to look if there is a
different way to solve this as I am guessing you are actually using adj_mode in
the manner it was intended.
Otherwise this patch series is working on BeagleBone Black - I have only tried
video so far (not audio).
Darren
=8<
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v4 12/24] drm/i2c: tda998x: check the CEC device creation
From: Russell King - ARM Linux @ 2014-01-27 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181443.7981862e@armhf>
On Sat, Jan 25, 2014 at 06:14:43PM +0100, Jean-Francois Moine wrote:
> This patch checks if the CEC device is well created at intialization
> time.
>
> Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v4 24/24] drm/i2c: tda998x: adjust the audio clock divider for S/PDIF
From: Russell King - ARM Linux @ 2014-01-27 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181436.5c443251@armhf>
On Sat, Jan 25, 2014 at 06:14:36PM +0100, Jean-Francois Moine wrote:
> According to some tests on the Cubox (Marvell Armada 510 + TDA19988),
> the S/PDIF input asks for a greater audio clock divider.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index b4827c0..e4dfcb4 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -679,10 +679,14 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> * There is no detailed info in the datasheet, so we just
> * assume 100MHz requires larger divider.
> */
> + adiv = AUDIO_DIV_SERCLK_8;
> if (mode->clock > 100000)
> - adiv = AUDIO_DIV_SERCLK_16;
> - else
> - adiv = AUDIO_DIV_SERCLK_8;
> + adiv++; /* AUDIO_DIV_SERCLK_8 */
> +
> + /* S/PDIF asks for a larger divider */
> + if (p->audio_format == AFMT_SPDIF)
> + adiv++; /* AUDIO_DIV_SERCLK_16 or _32 */
I'm not sure these comments are quite right... You start off with
adiv at AUDIO_DIV_SERCLK_8, and then you increment it, but the
comment says it's AUDIO_DIV_SERCLK_8 ? Shouldn't it become
AUDIO_DIV_SERCLK_16 ?
Please review the above change yourself. :)
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v4 15/24] drm/i2c: tda998x: use irq for connection status and EDID read
From: Russell King - ARM Linux @ 2014-01-27 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181438.1353afc7@armhf>
On Sat, Jan 25, 2014 at 06:14:38PM +0100, Jean-Francois Moine wrote:
> This patch adds the optional treatment of the tda998x IRQ.
>
> The interrupt function is used to know the display connection status
> without polling and to speedup reading the EDID.
>
> The IRQ number is defined in the i2c client either by platform data or
> in the DT.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
I don't see where you free the interrupt in this - you used to, but it
appears that hunk got dropped?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Yann Droneaud @ 2014-01-27 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127181836.GH26766@pengutronix.de>
Hi,
Le lundi 27 janvier 2014 ? 19:18 +0100, Uwe Kleine-K?nig a ?crit :
> On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
> > The dma_mask for a device structure is a pointer. This pointer
> > needs to be set up before the dma mask can actually be set. Most
> > frameworks in the kernel take care of setting this up properly but
> > platform devices that don't follow a regular bus structure may not
> > ever have this set. As a result, checks such as dma_capable will
> > always return false on a raw platform device and dma_set_mask will
> > always return -EIO. Fix this by adding a dma_mask in the
> > platform_device archdata and setting it to be the dma_mask. Devices
> > used in other frameworks can change this as needed.
> >
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Suggested-by: Kumar Gala <galak@codeaurora.org>
> > Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> Hello,
>
> there is another non-platform dependant approach available, that might
> be worth to evaluate:
>
> http://mid.gmane.org/1390817152-30898-1-git-send-email-ydroneaud at opteya.com
>
ARM, even AAAAARGH64 [1], doesn't need a special treatement regarding
the infamous dma_mask pointer. So perhaps my solution is better.
This solution (adding dma_mask in pdev_archdata) is already in use in
powerpc architecture. See arch/powerpc/kernel/setup-common.c
The advantage of this solution is that it makes a dma_mask placeholder
available to statically allocated platform_device struct, while mine
only address the problem for platform_device struct allocated with
platform_device_alloc().
A possible drawback of adding dma_mask in pdev_archdata and setting the
pointer in arch_setup_pdev_archdata() may be that a dma_mask setup prior
calling platform_device_register() got overwritten.
For example at91rm9200_usbh_device in
arch/arm/mach-at91/at91rm9200_devices.c (it's the first occurence
returned by cscope).
So I guess there's not yet a perfect solution (add dma_mask to struct
platform_device instead of hidding it either in struct pdev_archdata or
struct platform_object ?).
BTW, I've started to convert some drivers just to try my first option.
I'm also considering using dma_set_mask_and_coherent() in
platform_device_register_full() and drivers using
platform_device_alloc(). But I'm not sure about it : will it break
something with the additionals check on the mask, just as the failure
reported in the message ("dma_set_mask will always return -EIO.") ?
[1]
http://lkml.kernel.org/r/20140124154002.GF31570 at twins.programming.kicks-ass.net
Regards.
--
Yann Droneaud
OPTEYA
^ permalink raw reply
* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Mike Turquette @ 2014-01-27 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390047057-2239-2-git-send-email-thomas.ab@samsung.com>
Quoting Thomas Abraham (2014-01-18 04:10:51)
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> On some platforms such as the Samsung Exynos, changing the frequency
> of the CPU clock requires changing the frequency of the PLL that is
> supplying the CPU clock. To change the frequency of the PLL, the CPU
> clock is temporarily reparented to another parent clock.
>
> The clock frequency of this temporary parent clock could be much higher
> than the clock frequency of the PLL at the time of reparenting. Due
> to the temporary increase in the CPU clock speed, the CPU (and any other
> components in the CPU clock domain such as dividers, mux, etc.) have to
> to be operated at a higher voltage level, called the safe voltage level.
> This patch adds optional support to temporarily switch to a safe voltage
> level during CPU frequency transitions.
>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
I'm not a fan of this change. This corner case should be abstracted away
somehow. I had talked to Chander Kayshap previously about handling
voltage changes in clock notifier callbacks, which then renders any
voltage change as a trivial part of the clock rate transition. That
means that this "safe voltage" thing could be handled automagically
without any additional code in the CPUfreq driver.
There are two nice ways to do this with the clock framework. First is
explicit re-parenting with voltage scaling done in the clock rate-change
notifiers:
clk_set_parent(cpu_clk, temp_parent);
/* implicit voltage scaling to "safe voltage" happens above */
clk_set_rate(pll, some_rate);
clk_set_parent(cpu_clk, pll);
/* implicit voltage scaling to nominal OPP voltage happens above */
The above sequence would require a separate exnyos CPUfreq driver, due
to the added clk_set_parent logic.
The second way to do this is to abstract the clk re-muxing logic out
into the clk driver, which would allow cpufreq-cpu0 to be used for the
exynos chips.
I'm more a fan of explicitly listing the Exact Steps for the cpu opp
transition in a separate exynos-specific CPUfreq driver, but that's
probably an unpopular view.
Regards,
Mike
> ---
> .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 ++++
> drivers/cpufreq/cpufreq-cpu0.c | 37 +++++++++++++++++--
> 2 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> index f055515..37453ab 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> @@ -19,6 +19,12 @@ Optional properties:
> - cooling-min-level:
> - cooling-max-level:
> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
> +- safe-opp: Certain platforms require that during a opp transition,
> + a system should not go below a particular opp level. For such systems,
> + this property specifies the minimum opp to be maintained during the
> + opp transitions. The safe-opp value is a tuple with first element
> + representing the safe frequency and the second element representing the
> + safe voltage.
>
> Examples:
>
> @@ -36,6 +42,7 @@ cpus {
> 396000 950000
> 198000 850000
> >;
> + safe-opp = <396000 950000>
> clock-latency = <61036>; /* two CLK32 periods */
> #cooling-cells = <2>;
> cooling-min-level = <0>;
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 0c12ffc..075d3d1 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -27,6 +27,8 @@
>
> static unsigned int transition_latency;
> static unsigned int voltage_tolerance; /* in percentage */
> +static unsigned long safe_frequency;
> +static unsigned long safe_voltage;
>
> static struct device *cpu_dev;
> static struct clk *cpu_clk;
> @@ -64,17 +66,30 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
> volt_old = regulator_get_voltage(cpu_reg);
> }
>
> - pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
> + pr_debug("\n\n%u MHz, %ld mV --> %u MHz, %ld mV\n",
> old_freq / 1000, volt_old ? volt_old / 1000 : -1,
> new_freq / 1000, volt ? volt / 1000 : -1);
>
> /* scaling up? scale voltage before frequency */
> - if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
> + if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
> + new_freq >= safe_frequency) {
> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> if (ret) {
> pr_err("failed to scale voltage up: %d\n", ret);
> return ret;
> }
> + } else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
> + /*
> + * the scaled up voltage level for the new_freq is lower
> + * than the safe voltage level. so set safe_voltage
> + * as the intermediate voltage level and revert it
> + * back after the frequency has been changed.
> + */
> + ret = regulator_set_voltage_tol(cpu_reg, safe_voltage, tol);
> + if (ret) {
> + pr_err("failed to set safe voltage: %d\n", ret);
> + return ret;
> + }
> }
>
> ret = clk_set_rate(cpu_clk, freq_exact);
> @@ -86,7 +101,8 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
> }
>
> /* scaling down? scale voltage after frequency */
> - if (!IS_ERR(cpu_reg) && new_freq < old_freq) {
> + if (!IS_ERR(cpu_reg) &&
> + (new_freq < old_freq || new_freq < safe_frequency)) {
> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> if (ret) {
> pr_err("failed to scale voltage down: %d\n", ret);
> @@ -116,6 +132,8 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
>
> static int cpu0_cpufreq_probe(struct platform_device *pdev)
> {
> + const struct property *prop;
> + struct dev_pm_opp *opp;
> struct device_node *np;
> int ret;
>
> @@ -165,13 +183,24 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
> goto out_put_node;
> }
>
> + prop = of_find_property(np, "safe-opp", NULL);
> + if (prop) {
> + if (prop->value && (prop->length / sizeof(u32)) == 2) {
> + const __be32 *val;
> + val = prop->value;
> + safe_frequency = be32_to_cpup(val++);
> + safe_voltage = be32_to_cpup(val);
> + } else {
> + pr_err("invalid safe-opp level specified\n");
> + }
> + }
> +
> of_property_read_u32(np, "voltage-tolerance", &voltage_tolerance);
>
> if (of_property_read_u32(np, "clock-latency", &transition_latency))
> transition_latency = CPUFREQ_ETERNAL;
>
> if (!IS_ERR(cpu_reg)) {
> - struct dev_pm_opp *opp;
> unsigned long min_uV, max_uV;
> int i;
>
> --
> 1.6.6.rc2
>
^ permalink raw reply
* [PATCH] clk: sunxi: fix overflow when setting up divided factors
From: Mike Turquette @ 2014-01-27 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390613561-28636-1-git-send-email-emilio@elopez.com.ar>
Quoting Emilio L?pez (2014-01-24 17:32:41)
> Currently, we are allocating space for two pointers, when we actually
> may need to store three of them (two divisors plus the original clock).
> Fix this, and change sizeof(type) to sizeof(*var) to keep checkpatch.pl
> happy.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Emilio L?pez <emilio@elopez.com.ar>
> ---
>
> Hi Mike,
>
> Is there any chance you can include this oneliner on your second part of
> the pull request to Linus?
Done.
Regards,
Mike
>
> Cheers,
>
> Emilio
>
> drivers/clk/sunxi/clk-sunxi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 659e4ea..abb6c5a 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -875,7 +875,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
> if (!clk_data)
> return;
>
> - clks = kzalloc(SUNXI_DIVS_MAX_QTY * sizeof(struct clk *), GFP_KERNEL);
> + clks = kzalloc((SUNXI_DIVS_MAX_QTY+1) * sizeof(*clks), GFP_KERNEL);
> if (!clks)
> goto free_clkdata;
>
> --
> 1.8.5.3
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox