* [PATCH] arm64: add DSB after icache flush in __flush_icache_all()
From: Vinayak Kale @ 2014-01-27 11:59 UTC (permalink / raw)
To: linux-arm-kernel
Add DSB after icache flush operation.
Signed-off-by: Vinayak Kale <vkale@apm.com>
---
arch/arm64/include/asm/cacheflush.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index fea9ee3..88932498 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -116,6 +116,7 @@ extern void flush_dcache_page(struct page *);
static inline void __flush_icache_all(void)
{
asm("ic ialluis");
+ dsb();
}
#define flush_dcache_mmap_lock(mapping) \
--
1.7.9.5
^ permalink raw reply related
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-27 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125.101546.1134862463481697494.apm@brigitte.kvy.fi>
On Sat, Jan 25, 2014 at 08:15:46AM +0000, Antti P Miettinen wrote:
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Subject: [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
> Date: Mon, 20 Jan 2014 17:47:59 +0000
> > + - latency
> > + Usage: Required
> > + Value type: <prop-encoded-array>
> > + Definition: List of u32 values representing worst case latency
> > + in microseconds required to enter and exit the
> > + C-state, one value per OPP [2]. The list should
> > + be specified in the same order as the operating
> > + points property list of the cpu this state is
> > + valid on.
> > + If no OPP bindings are present, the latency value
> > + is associated with the current OPP of CPUs in the
> > + system.
>
> I'm afraid the CPU OPP is not enough to capture the variance in
> latencies. Especially memory frequency affects some of the latencies
> very stronly.
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.
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH v5 07/14] ahci-platform: "Library-ise" ahci_probe functionality
From: Hans de Goede @ 2014-01-27 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E63D08.6080704@ti.com>
Hi,
On 01/27/2014 12:03 PM, Roger Quadros wrote:
> On 01/27/2014 12:51 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/27/2014 11:39 AM, Roger Quadros wrote:
>>> Hi,
>>>
>>> On 01/22/2014 09:04 PM, Hans de Goede wrote:
>>
>> <snip>
>>
>>>> --- a/include/linux/ahci_platform.h
>>>> +++ b/include/linux/ahci_platform.h
>>>> @@ -20,7 +20,13 @@
>>>> struct device;
>>>> struct ata_port_info;
>>>> struct ahci_host_priv;
>>>> +struct platform_device;
>>>>
>>>> +/*
>>>> + * Note ahci_platform_data is deprecated. New drivers which need to override
>>>> + * any of these, should instead declare there own platform_driver struct, and
>>>> + * use ahci_platform* functions in their own probe, suspend and resume methods.
>>>> + */
>>>> struct ahci_platform_data {
>>>> int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
>>>> void (*exit)(struct device *dev);
>>>> @@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
>>>> void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
>>>> int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
>>>> void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
>>>> +struct ahci_host_priv *ahci_platform_get_resources(
>>>> + struct platform_device *pdev);
>>>
>>> Why not use 'struct device' as the argument?
>>
>> Because of calls to platform_get_resource inside the function.
>>
>>>> +void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
>>>
>>> Can we have 'struct device' as the argument? Else it becomes
>>> impossible to get 'struct device' from 'hpriv' if we need to call e.g.
>>> pm_runtime_*() APIs.
>>
>> The plan for is for this function to go away once we have a
>> devm version of of_clk_get, so if you need to put pm_runtime_calls
>> somewhere, please don't put them here. This sounds like something which
>> should go in enable / disable resources instead ?
>
> OK. I need to add pm_runtime_enable() + pm_runtime_get_sync() during
> initialization and pm_runtime_put_sync() + pm_runtime_disable() during cleanup.
Note that enable / disable resources will get called by (the default implementations
of) suspend / resume too.
If that is undesirable then I take back what I said before and
ahci_platform_put_resources' prototype should be changed to:
void ahci_platform_put_resources(struct device *dev, struct ahci_host_priv *hpriv);
And we will need to keep it around even after we get devm_of_clk_get.
> If ahci_platform_enable/disable_resources is the right place then we must be
> able to access struct device from there.
Right, and if not we need to access it from ahci_platform_put_resources(),
which is in essence the same problem.
> Is it a good to add 'struct device *dev' into the 'struct ahci_host_priv'?
> Then you can leave this series as is and i'll add a new patch for that.
Normally we get a device * as argument, and get to hpriv like this:
struct ata_host *host = dev_get_drvdata(dev);
struct ahci_host_priv *hpriv = host->private_data;
So having a dev * in hpriv is normally not useful.
But the ata_host gets allocated after the first ahci_platform_enable_resources
call, so we cannot use this there. Likewise disable_resources / put_resources
is used in error handling paths in probe where we don't have an ata_host yet,
so my vote goes to adding a "struct device *dev" as first argument, like I
suggested above for ahci_platform_put_resources.
This can be done as an add-on patch (if you do don't forget to also fix
ahci_sunxi.c and ahci_imx.c), or I can respin my series to have this from
day one.
If you want me to do a respin, please let me know which fix you'll need
(the put_resources or the enable/disable one).
Thanks & Regards,
Hans
^ permalink raw reply
* [PATCH 17/20] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer
From: Mark Rutland @ 2014-01-27 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389961514-13562-18-git-send-email-hanjun.guo@linaro.org>
On Fri, Jan 17, 2014 at 12:25:11PM +0000, Hanjun Guo wrote:
> ACPI GTDT (Generic Timer Description Table) contains information for
> arch timer initialization, this patch use this table to probe arm timer.
>
> GTDT table is used for ARM/ARM64 only, please refer to chapter 5.2.24
> of ACPI 5.0 spec for detailed inforamtion
>
> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/clocksource/arm_arch_timer.c | 100 +++++++++++++++++++++++++++++-----
> 1 file changed, 85 insertions(+), 15 deletions(-)
[...]
> +static void __init register_arch_interrupt(u32 interrupt, u32 flags,
> + int *arch_timer_ppi)
> +{
> + int trigger, polarity;
> +
> + if (!interrupt || !arch_timer_ppi)
> + return;
> +
> + trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
> + : ACPI_LEVEL_SENSITIVE;
> +
> + polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
> + : ACPI_ACTIVE_HIGH;
> +
> + *arch_timer_ppi = acpi_register_gsi(NULL, interrupt, trigger,
> + polarity);
> +}
Why does this take a pointer to the irq rather than returning the irq
(as with irq_of_parse_and_map)?
This looks awfully generic. Are the timer interrupts encoded specially
or is this useful for parsing other interrupts?
> +
> +static int __init acpi_parse_gtdt(struct acpi_table_header *table)
> +{
> + struct acpi_table_gtdt *gtdt;
> +
> + gtdt = (struct acpi_table_gtdt *)table;
> + if (!gtdt)
> + return -EINVAL;
> +
> + arch_timer_rate = arch_timer_get_cntfrq();
> +
> + if (!arch_timer_rate) {
> + pr_warn("arch_timer: Could not get frequency from CNTFREG\n");
s/CNTFREG/CNTFREQ/
This is probably worth a pr_err at least, the system is unlikely to get
very far if the timers don't work.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] ARM: mm: Fix stage-2 device memory attributes
From: Marc Zyngier @ 2014-01-27 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124233703.GA889@cbox>
On 24/01/14 23:37, Christoffer Dall wrote:
> On Sat, Jan 04, 2014 at 08:27:23AM -0800, Christoffer Dall wrote:
>> The stage-2 memory attributes are distinct from the Hyp memory
>> attributes and the Stage-1 memory attributes. We were using the stage-1
>> memory attributes for stage-2 mappings causing device mappings to be
>> mapped as normal memory. Add the S2 equivalent defines for memory
>> attributes and fix the comments explaining the defines while at it.
>>
>> Add a prot_pte_s2 field to the mem_type struct and fill out the field
>> for device mappings accordingly.
>>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> ---
>> Changelog[v2]:
>> - Guard the use of L_PTE_S2 defines with s2_policy to allow non-LPAE compiles.
>>
>> arch/arm/include/asm/pgtable-3level.h | 20 +++++++++++++-------
>> arch/arm/mm/mm.h | 1 +
>> arch/arm/mm/mmu.c | 15 ++++++++++++++-
>> 3 files changed, 28 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
>> index 4f95039..d5e04d6 100644
>> --- a/arch/arm/include/asm/pgtable-3level.h
>> +++ b/arch/arm/include/asm/pgtable-3level.h
>> @@ -120,13 +120,19 @@
>> /*
>> * 2nd stage PTE definitions for LPAE.
>> */
>> -#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
>> -#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
>> -#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
>> -#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
>> -#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
>> -
>> -#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
>> +#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
>> +#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
>> +#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
>> +#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
>> +#define L_PTE_S2_MT_DEV_NONSHARED (_AT(pteval_t, 0x1) << 2) /* device */
>> +#define L_PTE_S2_MT_DEV_WC (_AT(pteval_t, 0x5) << 2) /* normal non-cacheable */
>> +#define L_PTE_S2_MT_DEV_CACHED (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
>> +#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
>> +
>> +#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
>> +#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
>> +
>> +#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
>>
>> /*
>> * Hyp-mode PL2 PTE definitions for LPAE.
>> diff --git a/arch/arm/mm/mm.h b/arch/arm/mm/mm.h
>> index d5a982d..7ea641b 100644
>> --- a/arch/arm/mm/mm.h
>> +++ b/arch/arm/mm/mm.h
>> @@ -38,6 +38,7 @@ static inline pmd_t *pmd_off_k(unsigned long virt)
>>
>> struct mem_type {
>> pteval_t prot_pte;
>> + pteval_t prot_pte_s2;
>> pmdval_t prot_l1;
>> pmdval_t prot_sect;
>> unsigned int domain;
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index 580ef2d..44d571f 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -231,36 +231,48 @@ __setup("noalign", noalign_setup);
>> #endif /* ifdef CONFIG_CPU_CP15 / else */
>>
>> #define PROT_PTE_DEVICE L_PTE_PRESENT|L_PTE_YOUNG|L_PTE_DIRTY|L_PTE_XN
>> +#define PROT_PTE_S2_DEVICE PROT_PTE_DEVICE
>> #define PROT_SECT_DEVICE PMD_TYPE_SECT|PMD_SECT_AP_WRITE
>>
>> static struct mem_type mem_types[] = {
>> [MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
>> .prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
>> L_PTE_SHARED,
>> + .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
>> + s2_policy(L_PTE_S2_MT_DEV_SHARED) |
>> + L_PTE_SHARED,
>> .prot_l1 = PMD_TYPE_TABLE,
>> .prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
>> .domain = DOMAIN_IO,
>> },
>> [MT_DEVICE_NONSHARED] = { /* ARMv6 non-shared device */
>> .prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_NONSHARED,
>> + .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
>> + s2_policy(L_PTE_S2_MT_DEV_NONSHARED),
>> .prot_l1 = PMD_TYPE_TABLE,
>> .prot_sect = PROT_SECT_DEVICE,
>> .domain = DOMAIN_IO,
>> },
>> [MT_DEVICE_CACHED] = { /* ioremap_cached */
>> .prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_CACHED,
>> + .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
>> + s2_policy(L_PTE_S2_MT_DEV_CACHED),
>> .prot_l1 = PMD_TYPE_TABLE,
>> .prot_sect = PROT_SECT_DEVICE | PMD_SECT_WB,
>> .domain = DOMAIN_IO,
>> },
>> [MT_DEVICE_WC] = { /* ioremap_wc */
>> .prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_WC,
>> + .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
>> + s2_policy(L_PTE_S2_MT_DEV_WC),
>> .prot_l1 = PMD_TYPE_TABLE,
>> .prot_sect = PROT_SECT_DEVICE,
>> .domain = DOMAIN_IO,
>> },
>> [MT_UNCACHED] = {
>> .prot_pte = PROT_PTE_DEVICE,
>> + .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
>> + s2_policy(L_PTE_S2_MT_UNCACHED),
>> .prot_l1 = PMD_TYPE_TABLE,
>> .prot_sect = PMD_TYPE_SECT | PMD_SECT_XN,
>> .domain = DOMAIN_IO,
>> @@ -458,7 +470,8 @@ static void __init build_mem_type_table(void)
>> cp = &cache_policies[cachepolicy];
>> vecs_pgprot = kern_pgprot = user_pgprot = cp->pte;
>> s2_pgprot = cp->pte_s2;
>> - hyp_device_pgprot = s2_device_pgprot = mem_types[MT_DEVICE].prot_pte;
>> + hyp_device_pgprot = mem_types[MT_DEVICE].prot_pte;
>> + s2_device_pgprot = mem_types[MT_DEVICE].prot_pte_s2;
>>
>> /*
>> * ARMv6 and above have extended page tables.
>> --
>> 1.8.5
>>
>
> Ping?
Lost that one in the flurry of endianness bike shedding messages.
The change makes sense to me. arm64 uses a slightly different approach,
by using a PTE_S2_MEMATTR macro, but I'm not sure that would work for ARM.
Russell, Catalin: could you please have a look at this?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 0/2] Replace /include/ (dtc) with #include
From: Pankaj Dubey @ 2014-01-27 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389348970-5498-1-git-send-email-pankaj.dubey@samsung.com>
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.
Best Regards,
Pankaj Dubey
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Srikanth Thokala @ 2014-01-27 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140126135933.GD10628@intel.com>
Hi Vinod,
On Sun, Jan 26, 2014 at 7:29 PM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
>> On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
>> > Hi Lars,
>> >
>> > On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>> >> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
>> >> [...]
>> >>> +/**
>> >>> + * xilinx_vdma_device_control - Configure DMA channel of the device
>> >>> + * @dchan: DMA Channel pointer
>> >>> + * @cmd: DMA control command
>> >>> + * @arg: Channel configuration
>> >>> + *
>> >>> + * Return: '0' on success and failure value on error
>> >>> + */
>> >>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
>> >>> + enum dma_ctrl_cmd cmd, unsigned long arg)
>> >>> +{
>> >>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
>> >>> +
>> >>> + switch (cmd) {
>> >>> + case DMA_TERMINATE_ALL:
>> >>> + xilinx_vdma_terminate_all(chan);
>> >>> + return 0;
>> >>> + case DMA_SLAVE_CONFIG:
>> >>> + return xilinx_vdma_slave_config(chan,
>> >>> + (struct xilinx_vdma_config *)arg);
>> >>
>> >> You really shouldn't be overloading the generic API with your own semantics.
>> >> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
>> >
>> > Ok. The driver needs few additional configuration from the slave
>> > device like Vertical
>> > Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
>> > suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
>> > defined for Freescale drivers?
>>
>> In my opinion it is not a good idea to have driver implement a generic API,
>> but at the same time let the driver have custom semantics for those API
>> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
>> values passed to gpio_set_value instead of 0 and 1. It completely defeats
>> the purpose of a generic API, namely that you are able to write generic code
>> that makes use of the API without having to know about which implementation
>> API it is talking to. The dmaengine framework provides the
>> dmaengine_prep_interleaved_dma() function to setup two dimensional
>> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
>
> The question here i think would be waht this device supports? Is the hardware
> capable of doing interleaved transfers, then would make sense.
>
> While we do try to get users use dma_slave_config, but there will always be
> someone who have specfic params. If we can generalize then we might want to add
> to the dma_slave_config as well
There are many configuration parameters which are specific to IP and I
would like to
give an overview of some of parameteres here:
1) Park Mode ('cfg->park'): In Park mode, engine will park on frame
referenced by
'cfg->park_frm', so user will have control on each frame in this mode.
2) Interrupt Coalesce ('cfg->coalesce'): Used for setting interrupt
threshold. This value
determines the number of frame buffers to process. To use this feature,
'cfg->frm_cnt_en' should be set.
3) Frame Synchronization Source ('cfg->ext_fsync'): Can be an
external/internal frame
synchronization source. Used to synchronize one channel (MM2S/S2MM) with
another (S2MM/MM2S) channel.
4) Genlock Synchronization ('cfg->genlock'): Used to avoid mismatch rate between
master and slave. In master mode (cfg->master), frames are not dropped and
slave can drop frames to adjust to master frame rate.
And in future, this Engine being a soft IP, we could expect some more additional
parameters. Isn't a good idea to have a private member in dma_slave_config for
sharing additional configuration between slave device and dma engine? Or a new
dma_ctrl_cmd like FSLDMA_EXTERNAL_START?
Srikanth
>
> --
> ~Vinod
> --/EX
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] arm64: dts: add <dt-bindings/> symlink
From: Pankaj Dubey @ 2014-01-27 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140110115432.21fb03af@ipc1.ka-ro>
On 01/10/2014 07:54 PM, Lothar Wa?mann wrote:
> Hi,
>
> Pankaj Dubey wrote:
>> On 01/10/2014 06:22 PM, Lothar Wa?mann wrote:
>>> Hi,
>>>
>>> Pankaj Dubey wrote:
>>>> Add symlink to include/dt-bindings from arch/arm64/boot/dts/include/ to
>>>> match the ones in ARM architectures so that preprocessed device
>>>> tree files can include various useful constant definitions.
>>>>
>>>> See commit c58299a (kbuild: create an "include chroot" for DT bindings)
>>>> merged in v3.10-rc1 for details.
>>>>
>>>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>>>> ---
>>>> arch/arm64/boot/dts/include/dt-bindings | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>> create mode 120000 arch/arm64/boot/dts/include/dt-bindings
>>>>
>>>> diff --git a/arch/arm64/boot/dts/include/dt-bindings b/arch/arm64/boot/dts/include/dt-bindings
>>>> new file mode 120000
>>>> index 0000000..08c00e4
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/include/dt-bindings
>>>> @@ -0,0 +1 @@
>>>> +../../../../../include/dt-bindings
>>>> \ No newline at end of file
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> I just created symlink file to "include/dt-bindings", and when created
>> patch it is showing this line
>> at the end of patch. I do not have much idea why this came in patch? But
>> when I checked similar patches
>> it looks like it is required.
>>
> I noticed after sending the email, that the file in question was
> actually only a symlink. The message seems to be a 'feature' of
> 'patch' when dealing with symlinks.
>
>
> Lothar Wa?mann
Gentle Ping.
Best Regards,
Pankaj Dubey
^ permalink raw reply
* [PATCH v5 07/14] ahci-platform: "Library-ise" ahci_probe functionality
From: Roger Quadros @ 2014-01-27 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E63A1F.6080301@redhat.com>
On 01/27/2014 12:51 PM, Hans de Goede wrote:
> Hi,
>
> On 01/27/2014 11:39 AM, Roger Quadros wrote:
>> Hi,
>>
>> On 01/22/2014 09:04 PM, Hans de Goede wrote:
>
> <snip>
>
>>> --- a/include/linux/ahci_platform.h
>>> +++ b/include/linux/ahci_platform.h
>>> @@ -20,7 +20,13 @@
>>> struct device;
>>> struct ata_port_info;
>>> struct ahci_host_priv;
>>> +struct platform_device;
>>>
>>> +/*
>>> + * Note ahci_platform_data is deprecated. New drivers which need to override
>>> + * any of these, should instead declare there own platform_driver struct, and
>>> + * use ahci_platform* functions in their own probe, suspend and resume methods.
>>> + */
>>> struct ahci_platform_data {
>>> int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
>>> void (*exit)(struct device *dev);
>>> @@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
>>> void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
>>> int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
>>> void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
>>> +struct ahci_host_priv *ahci_platform_get_resources(
>>> + struct platform_device *pdev);
>>
>> Why not use 'struct device' as the argument?
>
> Because of calls to platform_get_resource inside the function.
>
>>> +void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
>>
>> Can we have 'struct device' as the argument? Else it becomes
>> impossible to get 'struct device' from 'hpriv' if we need to call e.g.
>> pm_runtime_*() APIs.
>
> The plan for is for this function to go away once we have a
> devm version of of_clk_get, so if you need to put pm_runtime_calls
> somewhere, please don't put them here. This sounds like something which
> should go in enable / disable resources instead ?
OK. I need to add pm_runtime_enable() + pm_runtime_get_sync() during
initialization and pm_runtime_put_sync() + pm_runtime_disable() during cleanup.
If ahci_platform_enable/disable_resources is the right place then we must be
able to access struct device from there.
Is it a good to add 'struct device *dev' into the 'struct ahci_host_priv'?
Then you can leave this series as is and i'll add a new patch for that.
If there is a better way, please let me know.
cheers,
-roger
^ permalink raw reply
* [PATCH v5 07/14] ahci-platform: "Library-ise" ahci_probe functionality
From: Hans de Goede @ 2014-01-27 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E63778.5000509@ti.com>
Hi,
On 01/27/2014 11:39 AM, Roger Quadros wrote:
> Hi,
>
> On 01/22/2014 09:04 PM, Hans de Goede wrote:
<snip>
>> --- a/include/linux/ahci_platform.h
>> +++ b/include/linux/ahci_platform.h
>> @@ -20,7 +20,13 @@
>> struct device;
>> struct ata_port_info;
>> struct ahci_host_priv;
>> +struct platform_device;
>>
>> +/*
>> + * Note ahci_platform_data is deprecated. New drivers which need to override
>> + * any of these, should instead declare there own platform_driver struct, and
>> + * use ahci_platform* functions in their own probe, suspend and resume methods.
>> + */
>> struct ahci_platform_data {
>> int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
>> void (*exit)(struct device *dev);
>> @@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
>> void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
>> int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
>> void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
>> +struct ahci_host_priv *ahci_platform_get_resources(
>> + struct platform_device *pdev);
>
> Why not use 'struct device' as the argument?
Because of calls to platform_get_resource inside the function.
>> +void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
>
> Can we have 'struct device' as the argument? Else it becomes
> impossible to get 'struct device' from 'hpriv' if we need to call e.g.
> pm_runtime_*() APIs.
The plan for is for this function to go away once we have a
devm version of of_clk_get, so if you need to put pm_runtime_calls
somewhere, please don't put them here. This sounds like something which
should go in enable / disable resources instead ?
Regards,
Hans
^ permalink raw reply
* [PATCH] drivers: bus: fix CCI driver kcalloc call parameters swap
From: Lorenzo Pieralisi @ 2014-01-27 10:50 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes a bug/typo in the CCI driver kcalloc usage
that inadvertently swapped the parameters order in the
kcalloc call and went unnoticed.
Reported-by: Xia Feng <xiafeng@allwinnertech.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
drivers/bus/arm-cci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index b6739cb..962fd35 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -979,7 +979,7 @@ static int cci_probe(void)
nb_cci_ports = cci_config->nb_ace + cci_config->nb_ace_lite;
- ports = kcalloc(sizeof(*ports), nb_cci_ports, GFP_KERNEL);
+ ports = kcalloc(nb_cci_ports, sizeof(*ports), GFP_KERNEL);
if (!ports)
return -ENOMEM;
--
1.8.2.2
^ permalink raw reply related
* [PATCH v5 07/14] ahci-platform: "Library-ise" ahci_probe functionality
From: Roger Quadros @ 2014-01-27 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390417489-5354-8-git-send-email-hdegoede@redhat.com>
Hi,
On 01/22/2014 09:04 PM, Hans de Goede wrote:
> ahci_probe consists of 3 steps:
> 1) Get resources (get mmio, clks, regulator)
> 2) Enable resources, handled by ahci_platform_enable_resouces
> 3) The more or less standard ahci-host controller init sequence
>
> This commit refactors step 1 and 3 into separate functions, so the platform
> drivers for AHCI implementations which need a specific order in step 2,
> and / or need to do some custom register poking at some time, can re-use
> ahci-platform.c code without needing to copy and paste it.
>
> Note that ahci_platform_init_host's prototype takes the 3 non function
> members of ahci_platform_data as arguments, the idea is that drivers using
> the new exported utility functions will not use ahci_platform_data at all,
> and hopefully in the future ahci_platform_data can go away entirely.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/ata/ahci_platform.c | 158 ++++++++++++++++++++++++------------------
> include/linux/ahci_platform.h | 14 ++++
> 2 files changed, 106 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 1cce7a2..b260ebe 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -150,60 +150,31 @@ void ahci_platform_disable_resources(struct ahci_host_priv *hpriv)
> EXPORT_SYMBOL_GPL(ahci_platform_disable_resources);
>
>
> -static void ahci_put_clks(struct ahci_host_priv *hpriv)
> -{
> - int c;
> -
> - for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++)
> - clk_put(hpriv->clks[c]);
> -}
> -
> -static int ahci_probe(struct platform_device *pdev)
> +struct ahci_host_priv *ahci_platform_get_resources(
> + struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct ahci_platform_data *pdata = dev_get_platdata(dev);
> - const struct platform_device_id *id = platform_get_device_id(pdev);
> - struct ata_port_info pi = ahci_port_info[id ? id->driver_data : 0];
> - const struct ata_port_info *ppi[] = { &pi, NULL };
> struct ahci_host_priv *hpriv;
> - struct ata_host *host;
> - struct resource *mem;
> struct clk *clk;
> - int i, irq, max_clk, n_ports, rc;
> -
> - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!mem) {
> - dev_err(dev, "no mmio space\n");
> - return -EINVAL;
> - }
> -
> - irq = platform_get_irq(pdev, 0);
> - if (irq <= 0) {
> - dev_err(dev, "no irq\n");
> - return -EINVAL;
> - }
> -
> - if (pdata && pdata->ata_port_info)
> - pi = *pdata->ata_port_info;
> + int i, max_clk, rc;
>
> hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
> if (!hpriv) {
> dev_err(dev, "can't alloc ahci_host_priv\n");
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
> }
>
> - hpriv->flags |= (unsigned long)pi.private_data;
> -
> - hpriv->mmio = devm_ioremap(dev, mem->start, resource_size(mem));
> + hpriv->mmio = devm_ioremap_resource(dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> if (!hpriv->mmio) {
> - dev_err(dev, "can't map %pR\n", mem);
> - return -ENOMEM;
> + dev_err(dev, "no mmio space\n");
> + return ERR_PTR(-EINVAL);
> }
>
> hpriv->target_pwr = devm_regulator_get_optional(dev, "target");
> if (IS_ERR(hpriv->target_pwr)) {
> if (PTR_ERR(hpriv->target_pwr) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> + return ERR_PTR(-EPROBE_DEFER);
> hpriv->target_pwr = NULL;
> }
>
> @@ -223,27 +194,48 @@ static int ahci_probe(struct platform_device *pdev)
> hpriv->clks[i] = clk;
> }
>
> - rc = ahci_platform_enable_resources(hpriv);
> - if (rc)
> - goto free_clk;
> + return hpriv;
>
> - /*
> - * Some platforms might need to prepare for mmio region access,
> - * which could be done in the following init call. So, the mmio
> - * region shouldn't be accessed before init (if provided) has
> - * returned successfully.
> - */
> - if (pdata && pdata->init) {
> - rc = pdata->init(dev, hpriv);
> - if (rc)
> - goto disable_resources;
> - }
> +free_clk:
> + while (--i >= 0)
> + clk_put(hpriv->clks[i]);
> + return ERR_PTR(rc);
> +}
> +EXPORT_SYMBOL_GPL(ahci_platform_get_resources);
> +
> +void ahci_platform_put_resources(struct ahci_host_priv *hpriv)
> +{
> + int c;
> +
> + for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++)
> + clk_put(hpriv->clks[c]);
> +}
> +EXPORT_SYMBOL_GPL(ahci_platform_put_resources);
> +
> +
> +int ahci_platform_init_host(struct platform_device *pdev,
> + struct ahci_host_priv *hpriv,
> + const struct ata_port_info *pi_template,
> + unsigned int force_port_map,
> + unsigned int mask_port_map)
> +{
> + struct device *dev = &pdev->dev;
> + struct ata_port_info pi = *pi_template;
> + const struct ata_port_info *ppi[] = { &pi, NULL };
> + struct ata_host *host;
> + int i, irq, n_ports, rc;
>
> - ahci_save_initial_config(dev, hpriv,
> - pdata ? pdata->force_port_map : 0,
> - pdata ? pdata->mask_port_map : 0);
> + irq = platform_get_irq(pdev, 0);
> + if (irq <= 0) {
> + dev_err(dev, "no irq\n");
> + return -EINVAL;
> + }
>
> /* prepare host */
> + hpriv->flags |= (unsigned long)pi.private_data;
> +
> + ahci_save_initial_config(dev, hpriv, force_port_map, mask_port_map);
> +
> if (hpriv->cap & HOST_CAP_NCQ)
> pi.flags |= ATA_FLAG_NCQ;
>
> @@ -260,10 +252,8 @@ static int ahci_probe(struct platform_device *pdev)
> n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
>
> host = ata_host_alloc_pinfo(dev, ppi, n_ports);
> - if (!host) {
> - rc = -ENOMEM;
> - goto pdata_exit;
> - }
> + if (!host)
> + return -ENOMEM;
>
> host->private_data = hpriv;
>
> @@ -278,7 +268,8 @@ static int ahci_probe(struct platform_device *pdev)
> for (i = 0; i < host->n_ports; i++) {
> struct ata_port *ap = host->ports[i];
>
> - ata_port_desc(ap, "mmio %pR", mem);
> + ata_port_desc(ap, "mmio %pR",
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> ata_port_desc(ap, "port 0x%x", 0x100 + ap->port_no * 0x80);
>
> /* set enclosure management message type */
> @@ -292,13 +283,48 @@ static int ahci_probe(struct platform_device *pdev)
>
> rc = ahci_reset_controller(host);
> if (rc)
> - goto pdata_exit;
> + return rc;
>
> ahci_init_controller(host);
> ahci_print_info(host, "platform");
>
> - rc = ata_host_activate(host, irq, ahci_interrupt, IRQF_SHARED,
> - &ahci_platform_sht);
> + return ata_host_activate(host, irq, ahci_interrupt, IRQF_SHARED,
> + &ahci_platform_sht);
> +}
> +EXPORT_SYMBOL_GPL(ahci_platform_init_host);
> +
> +static int ahci_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct ahci_platform_data *pdata = dev_get_platdata(dev);
> + const struct platform_device_id *id = platform_get_device_id(pdev);
> + struct ahci_host_priv *hpriv;
> + int rc;
> +
> + hpriv = ahci_platform_get_resources(pdev);
> + if (IS_ERR(hpriv))
> + return PTR_ERR(hpriv);
> +
> + rc = ahci_platform_enable_resources(hpriv);
> + if (rc)
> + goto put_resources;
> +
> + /*
> + * Some platforms might need to prepare for mmio region access,
> + * which could be done in the following init call. So, the mmio
> + * region shouldn't be accessed before init (if provided) has
> + * returned successfully.
> + */
> + if (pdata && pdata->init) {
> + rc = pdata->init(dev, hpriv);
> + if (rc)
> + goto disable_resources;
> + }
> +
> + rc = ahci_platform_init_host(pdev, hpriv,
> + &ahci_port_info[id ? id->driver_data : 0],
> + pdata ? pdata->force_port_map : 0,
> + pdata ? pdata->mask_port_map : 0);
> if (rc)
> goto pdata_exit;
>
> @@ -308,8 +334,8 @@ pdata_exit:
> pdata->exit(dev);
> disable_resources:
> ahci_platform_disable_resources(hpriv);
> -free_clk:
> - ahci_put_clks(hpriv);
> +put_resources:
> + ahci_platform_put_resources(hpriv);
> return rc;
> }
>
> @@ -323,7 +349,7 @@ static void ahci_host_stop(struct ata_host *host)
> pdata->exit(dev);
>
> ahci_platform_disable_resources(hpriv);
> - ahci_put_clks(hpriv);
> + ahci_platform_put_resources(hpriv);
> }
>
> #ifdef CONFIG_PM_SLEEP
> diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
> index 5e5f85e..1dc7602 100644
> --- a/include/linux/ahci_platform.h
> +++ b/include/linux/ahci_platform.h
> @@ -20,7 +20,13 @@
> struct device;
> struct ata_port_info;
> struct ahci_host_priv;
> +struct platform_device;
>
> +/*
> + * Note ahci_platform_data is deprecated. New drivers which need to override
> + * any of these, should instead declare there own platform_driver struct, and
> + * use ahci_platform* functions in their own probe, suspend and resume methods.
> + */
> struct ahci_platform_data {
> int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
> void (*exit)(struct device *dev);
> @@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
> void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
> int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
> void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
> +struct ahci_host_priv *ahci_platform_get_resources(
> + struct platform_device *pdev);
Why not use 'struct device' as the argument?
> +void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
Can we have 'struct device' as the argument? Else it becomes
impossible to get 'struct device' from 'hpriv' if we need to call e.g.
pm_runtime_*() APIs.
> +int ahci_platform_init_host(struct platform_device *pdev,
> + struct ahci_host_priv *hpriv,
> + const struct ata_port_info *pi_template,
> + unsigned int force_port_map,
> + unsigned int mask_port_map);
>
> #endif /* _AHCI_PLATFORM_H */
>
cheers,
-roger
^ permalink raw reply
* [PATCH v10] clk: add MOXA ART SoCs clock driver
From: Mark Rutland @ 2014-01-27 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390308261-4026-1-git-send-email-jonas.jensen@gmail.com>
On Tue, Jan 21, 2014 at 12:44:21PM +0000, Jonas Jensen wrote:
> MOXA ART SoCs allow to determine PLL output and APB frequencies
> by reading registers holding multiplier and divisor information.
>
> Add a clock driver for this SoC.
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
> ---
>
> Notes:
> Thanks for the reply Sudeep, changes are in v10.
>
> Changes since v9:
>
> 1. rebase drivers/clk/Makefile to next-20140121
> 2. remove unnecessary switch
> 3. use a more elaborate commit message
>
> Applies to next-20140121
>
> .../bindings/clock/moxa,moxart-clock.txt | 48 +++++++++++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-moxart.c | 99 ++++++++++++++++++++++
> 3 files changed, 148 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
> create mode 100644 drivers/clk/clk-moxart.c
>
> diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
> new file mode 100644
> index 0000000..242e3fc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
> @@ -0,0 +1,48 @@
> +Device Tree Clock bindings for arch-moxart
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +MOXA ART SoCs allow to determine PLL output and APB frequencies
> +by reading registers holding multiplier and divisor information.
> +
> +
> +PLL:
> +
> +Required properties:
> +- compatible : Must be "moxa,moxart-pll-clock"
> +- #clock-cells : Should be 0
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle to parent clock
Nit: clocks are referenced with a clock-specifier (which might be zero
cells), not just a phandle.
How about:
clocks: should contain a phandle + clock-specifier for the parent clock
> +
> +Optional properties:
> +- clock-output-names : Should contain clock name
> +
> +
> +APB:
> +
> +Required properties:
> +- compatible : Must be "moxa,moxart-apb-clock"
> +- #clock-cells : Should be 0
> +- reg : Should contain registers location and length
> +- clocks : Should contain phandle to parent clock
Likewise.
> +
> +Optional properties:
> +- clock-output-names : Should contain clock name
> +
> +
> +For example:
> +
> + clk_pll: clk_pll at 98100000 {
> + compatible = "moxa,moxart-pll-clock";
> + #clock-cells = <0>;
> + reg = <0x98100000 0x34>;
> + };
> +
> + clk_apb: clk_apb at 98100000 {
> + compatible = "moxa,moxart-apb-clock";
> + #clock-cells = <0>;
> + reg = <0x98100000 0x34>;
> + clocks = <&clk_pll>;
> + };
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 58b2d72..24361bf 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK) += clk-composite.o
> # SoCs specific
> obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
> +obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
> obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
> obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
> obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
> diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
> new file mode 100644
> index 0000000..7021748
> --- /dev/null
> +++ b/drivers/clk/clk-moxart.c
> @@ -0,0 +1,99 @@
> +/*
> + * MOXA ART SoCs clock driver.
> + *
> + * Copyright (C) 2013 Jonas Jensen
> + *
> + * Jonas Jensen <jonas.jensen@gmail.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/io.h>
> +#include <linux/of_address.h>
> +#include <linux/clkdev.h>
> +
> +void __init moxart_of_pll_clk_init(struct device_node *node)
> +{
> + static void __iomem *base;
> + struct clk *clk, *ref_clk;
> + unsigned long rate;
> + unsigned int mul;
> + const char *name = node->name;
> +
> + of_property_read_string(node, "clock-output-names", &name);
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s: of_iomap failed\n", node->full_name);
> + return;
> + }
> +
> + mul = readl(base + 0x30) >> 3 & 0x3f;
> + iounmap(base);
> +
> + ref_clk = of_clk_get(node, 0);
> + if (IS_ERR(ref_clk)) {
> + pr_err("%s: of_clk_get failed\n", node->full_name);
> + return;
> + }
> +
> + rate = mul * clk_get_rate(ref_clk);
> +
> + clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
If this clock has a parent, Surely CLK_IS_ROOT is not appropriate by its
definition:
#define CLK_IS_ROOT BIT(4) /* root clk, has no parent */
Surely this is a fixed factor clock rather than a fixed rate clock?
> + if (IS_ERR(clk)) {
> + pr_err("%s: clk_register_fixed_rate failed\n", node->full_name);
> + return;
> + }
> +
> + clk_register_clkdev(clk, NULL, name);
> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
> +}
> +CLK_OF_DECLARE(moxart_pll_clock, "moxa,moxart-pll-clock",
> + moxart_of_pll_clk_init);
> +
> +void __init moxart_of_apb_clk_init(struct device_node *node)
> +{
> + static void __iomem *base;
> + struct clk *clk, *pll_clk;
> + unsigned long rate;
> + unsigned int div, val;
> + unsigned int div_idx[] = { 2, 3, 4, 6, 8};
> + const char *name = node->name;
> +
> + of_property_read_string(node, "clock-output-names", &name);
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s: of_iomap failed\n", node->full_name);
> + return;
> + }
> +
> + val = readl(base + 0xc) >> 4 & 0x7;
> + iounmap(base);
> +
> + if (val > 4)
> + val = 0;
> + div = div_idx[val];
> +
> + pll_clk = of_clk_get(node, 0);
> + if (IS_ERR(pll_clk)) {
> + pr_err("%s: of_clk_get failed\n", node->full_name);
> + return;
> + }
> +
> + rate = clk_get_rate(pll_clk) / (div * 2);
> +
> + clk = clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
Likewise.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Ulf Hansson @ 2014-01-27 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E54540.8080304@gmail.com>
On 26 January 2014 18:26, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> On 21.01.2014 19:34, Tomasz Figa wrote:
>>
>> Hi,
>>
>> On 20.01.2014 04:56, Olof Johansson wrote:
>>>
>>> This patch enables support for power-on sequencing of SDIO peripherals
>>> through DT.
>>>
>>> In general, it's quite common that wifi modules and other similar
>>> peripherals have several signals in addition to the SDIO interface that
>>> needs wiggling before the module will power on. It's common to have a
>>> reference clock, one or several power rails and one or several lines
>>> for reset/enable type functions.
>>>
>>> The binding as written today introduces a number of reset gpios,
>>> a regulator and a clock specifier. The code will handle up to 2 gpio
>>> reset lines, but it's trivial to increase to more than that if needed
>>> at some point.
>>>
>>> Implementation-wise, the MMC core has been changed to handle this during
>>> host power up, before the host interface is powered on. I have not yet
>>> implemented the power-down side, I wanted people to have a chance for
>>> reporting back w.r.t. issues (or comments on the bindings) first.
>>>
>>> I have not tested the regulator portion, since the system and module
>>> I'm working on doesn't need one (Samsung Chromebook with Marvell
>>> 8797-based wifi). Testing of those portions (and reporting back) would
>>> be appreciated.
>>
>>
>> While I fully agree that this is an important problem that needs to be
>> solved, I really don't think this is the right way, because:
>>
>> a) power-up sequence is really specific to the MMC device and often it's
>> not simply a matter of switching on one regulator or one clock, e.g.
>> specific time constraints need to be met.
>>
>> b) you can have WLAN chips in which SDIO is just one of the options to
>> use as host interface, which may be also HSIC, I2C or UART. Really. See
>> [1].
>>
>> c) this is leaking device specific details to generic host code, which
>> isn't really elegant.
>>
>> Now, to make this a bit more constructive, [2] is a solution that I came
>> up with (not perfect either), which simply adds a separate platform
>> device for the low level part of the chip. I believe this is a better
>> solution because:
>>
>> a) you can often see such WLAN/BT combo chip as a set of separate
>> devices, e.g. SDIO WLAN, UART BT and a simple PMIC or management IC,
>> which provides power/reset control, out of band signalling and etc. for
>> the first two, so it isn't that bad to have a separate device node for
>> the last one,
>>
>> b) you have full freedom of defining your DT binding with whatever data
>> you need, any number of clocks, regulators, GPIOs and even out of band
>> interrupts (IMHO the most important one).
>>
>> c) you can implement power-on, power-off sequences as needed for your
>> particular device,
>>
>> d) you have full separation of device-specific data from MMC core (or
>> any other subsystem simply used as a way to perform I/O to the chip).
>>
>> Now what's missing there is a way to signal the MMC core or any other
>> transport that a device showed up and the controller should be woken up
>> out of standby and scan of the bus initialized. This could be done by
>> explicitly specifying the device as a subnode of the
>> MMC/UART/USB(HSIC)/I2C or whatever with a link (phandle) to the power
>> controller of the chip or the other way around - a link to the
>> MMC/UART/... controller from the power controller node.
>
>
> I've looked a bit around MMC core code and got some basic idea how things
> look. I will definitely need some guidance, or at least some opinions, from
> MMC guys, as some MMC core changes are unavoidable.
>
> Now, the device-specific code is not really an issue, existing drivers
> usually already have their ways of powering the chips on and off, based on
> platform data. Everything needed here is to retrieve needed resources
> (GPIOs, clocks, regulators) using DT, which should be trivial.
>
> The worse part is the interaction between MMC and power controller driver
> (the platform driver part of WLAN driver, if you look at brcmfmac as an
> example). I believe that we need following things:
>
> a) A way to tell the MMC controller that there is no card detection
> mechanism available on given slot and it also should not be polling the slot
> to check card presence. Something like a "manual card detect" that would be
> triggered by another kernel entity that controls whether the MMC device is
> present (i.e. WLAN driver). We already have "broken-cd" property, but it
> only implies the former, wasting time on needless polling.
There is already a host capability that I think we could use to handle
this. MMC_CAP_NONREMOVABLE, the corresponding DT binding string is
"non-removable", and it may be set per host device.
Using this cap means the mmc_rescan process that runs to detect new
cards, will only be executed once and during boot. So, we need to make
sure all resources and powers are provided to the card at this point.
Otherwise the card will not be detected.
In the SDIO case, to save power, the SDIO func driver may use runtime
PM to tell the mmc core power about whether the card needs to be
powered. Typically from the WLAN driver's probe() and "interface
up/down" the runtime PM reference for the SDIO func device, should be
adjusted with pm_runtime_get|put.
>
> b) A mechanism to bind the power controller to used MMC slot. Something like
> "mmc-bus = <&mmc2>;" property in device node of the power controller and a
> function like of_find_mmc_controller_by_node(), which would be an MMC
> counterpart of I2C's of_find_i2c_adapter_by_node(). To avoid races, it
> should probably take a reference on MMC host that would have to be dropped
> explicitly whenever it is not needed anymore.
I suppose an "MMC slot" can be translated to "MMC host"?
What I am trying to understand is how the mmc core (or if we push it
to be handled from the mmc host's .set_ios callback) shall be able to
tell the power controller driver to enable/disable it's resources.
Somehow we need the struct device available to handle that. Then I
guess operating on it using runtime PM would be a solution that would
be quite nice!?
>
> c) A method to notify the MMC subsystem that card presence has changed. We
> already have something like this in drivers/mmc/core/slot-gpio.c, but used
> for a simple GPIO-based card detection. If the main part of
> mmc_gpio_cd_irqt() could be turned into an exported helper, e.g.
> mmc_force_card_detect(host) then basically we would have everything needed.
I am not sure I understand why this is needed. I think it would be
more convenient to use MMC_CAP_NONREMOVABLE instead as stated earlier.
But please elaborate, I might have missed something.
>
> Unfortunately, I don't have more time left for today to create patches and
> test them, so for now, I'd like to hear opinion of MMC maintainers about
> this approach. Do you find this acceptable?
>
> By the way, it seems like slot-gpio.c could replace a lot of custom GPIO
> card detection code used in MMC host drivers, e.g. sdhci-s3c. Is there any
> reason why it couldn't?
I suppose most host driver's should convert to the slot-gpio API, it's
is just a matter of someone to send the patches. :-)
Kind regards
Ulf Hansson
>
> Best regards,
> Tomasz
^ permalink raw reply
* [PATCHv2] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Will Deacon @ 2014-01-27 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390604955-6309-1-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Fri, Jan 24, 2014 at 11:09:15PM +0000, Laura Abbott wrote:
> arm64 currently lacks support for -fstack-protector. Add
> similar functionality to arm to detect stack corruption.
[...]
> +/*
> + * Initialize the stackprotector canary value.
> + *
> + * NOTE: this must only be called from functions that never return,
> + * and it must always be inlined.
> + */
> +static __always_inline void boot_init_stack_canary(void)
> +{
> + unsigned long canary;
> +
> + /* Try to get a semi random initial value. */
> + get_random_bytes(&canary, sizeof(canary));
> + canary ^= LINUX_VERSION_CODE;
> +
> + current->stack_canary = canary;
Do we actually need this line now?
Will
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Jyri Sarha @ 2014-01-27 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64RbXZS_5nvXf9_t=Q=+zrBa=eF-f-xcZTxaMLYSQkNrw@mail.gmail.com>
On 01/27/2014 10:54 AM, Chen-Yu Tsai wrote:
> Hi,
>
> On Mon, Jan 27, 2014 at 4:43 PM, Jyri Sarha <jsarha@ti.com> wrote:
>> On 01/24/2014 07:35 PM, Fabio Estevam wrote:
...
>> I have not received too much feedback to my patch yet. CCF is a bit new
>> territory to me, but I think having a separate stackable clk-gpio would be
>> more flexible than having the gpio property implemented in clk-fixed-rate.
>
> Not sure where stacking external clocks would be used, but sounds like a
> fixed factor clock? Maybe you should add DT support to that if that's what
> you need or have.
>
Ah, but then there is also the problem of having to change
clk_register_fixed_rate() in the CCF api, which is called from all over
the place.
Of course I could add a new clk_register_fixed_rate_gpio(), but still it
does not look to me like the way to go.
Cheers,
Jyri
^ permalink raw reply
* [PATCH v2 2/4] pinctrl: st: Add software edge trigger interrupt support.
From: Linus Walleij @ 2014-01-27 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124082859.GJ8586@lee--X1>
On Fri, Jan 24, 2014 at 9:28 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > +/*
>> > + * As edge triggers are not supported at hardware level, it is supported by
>> > + * software by exploiting the level trigger support in hardware.
>>
>> (...)
>>
>> All this is quite hard to understand. Maybe it's just because
>> it's hard overall. Edge triggers are not supported by hardware
>> so we use the hardware edge trigger support?
>>
>> That is a bit oxymoronic...
>
> That's not what is says. Read it again. :)
Argh yeah I was wrong ... it's perfectly consistent with the
implementation. Sorry for being such a slow brain this last
friday.
Yours,
Linus Walleij
^ permalink raw reply
* imx6: usbhc2/3 and HSIC
From: Lucas Stach @ 2014-01-27 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9NwWckD5Rmr9oW2Gr071V2p0FjRJcttYpB4qQNEWTxDEJ6qw@mail.gmail.com>
Hi Christian,
Am Montag, den 27.01.2014, 10:22 +0100 schrieb Christian Gmeiner:
> Hi all...
>
> does anyone used the usbhc2 or usbhc3 in HSIC mode? I am trying my
> luck but I do not
> get it to work. Is there anything special I need to take care of?
>
I remember we had this working on a board back in the 3.10 days. The
only thing I remember which is specific to HSIC is in the attached
patch. This isn't really clean and should be done in a better way for
mainline, but maybe it provides some pointers for you.
Regards,
Lucas
------------------------------>8------------------------------------
>From 5af9a0597a329a2c4af012fd0fb54f525b45f625 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Mon, 28 Jan 2013 13:08:08 +0100
Subject: [PATCH] ARM/USB i.MX6: Add HSIC support
On i.MX6 HOST2 and HOST3 are HSIC only ports. These have the special
requirement that they need the to set a pullup on the strobe line
after initialization.
Fortunately only one routing option for the HSIC ports exist, so we
can put the pinmux setup completely into the i.MX6 dtsi file.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
arch/arm/boot/dts/imx6q.dtsi | 32 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++++++
drivers/usb/chipidea/ci13xxx_imx.c | 10 ++++++++++
drivers/usb/chipidea/usbmisc_imx.c | 5 +++++
4 files changed, 55 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 21e675848bd1..18ffb5f91439 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -253,6 +253,38 @@
};
};
+ usbh2 {
+ pinctrl_usbh2: usbh2grp {
+ fsl,pins = <
+ MX6Q_PAD_RGMII_TXC__USB_H2_DATA 0x13030
+ MX6Q_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x13030
+ >;
+ };
+
+ pinctrl_usbh2_enabled: usbh2grp-enabled {
+ fsl,pins = <
+ MX6Q_PAD_RGMII_TXC__USB_H2_DATA 0x13030
+ MX6Q_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x17030
+ >;
+ };
+ };
+
+ usbh3 {
+ pinctrl_usbh3: usbh3grp-1 {
+ fsl,pins = <
+ MX6Q_PAD_RGMII_RX_CTL__USB_H3_DATA 0x13030
+ MX6Q_PAD_RGMII_RXC__USB_H3_STROBE 0x13030
+ >;
+ };
+
+ pinctrl_usbh3_enabled: usbh3grp-enabled {
+ fsl,pins = <
+ MX6Q_PAD_RGMII_RX_CTL__USB_H3_DATA 0x13030
+ MX6Q_PAD_RGMII_RXC__USB_H3_STROBE 0x17030
+ >;
+ };
+ };
+
usdhc2 {
pinctrl_usdhc2_1: usdhc2grp-1 {
fsl,pins = <
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9e8296e4c343..884c512eff04 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -626,7 +626,11 @@
interrupts = <0 41 0x04>;
clocks = <&clks 162>;
fsl,usbmisc = <&usbmisc 2>;
+ phy_type = "hsic";
status = "disabled";
+ pinctrl-names = "default", "enabled";
+ pinctrl-0 = <&pinctrl_usbh2>;
+ pinctrl-1 = <&pinctrl_usbh2_enabled>;
};
usbh3: usb at 02184600 {
@@ -635,7 +639,11 @@
interrupts = <0 42 0x04>;
clocks = <&clks 162>;
fsl,usbmisc = <&usbmisc 3>;
+ phy_type = "hsic";
status = "disabled";
+ pinctrl-names = "default", "enabled";
+ pinctrl-0 = <&pinctrl_usbh3>;
+ pinctrl-1 = <&pinctrl_usbh3_enabled>;
};
usbmisc: usbmisc: usbmisc at 02184800 {
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c b/drivers/usb/chipidea/ci13xxx_imx.c
index 2ec9052c7bb7..f770328d4901 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -99,6 +99,7 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
struct resource *res;
int ret;
struct usb_phy *phy;
+ struct pinctrl *pinctrl;
if (of_find_property(pdev->dev.of_node, "fsl,usbmisc", NULL)
&& !usbmisc_ops)
@@ -197,6 +198,15 @@ static int ci13xxx_imx_probe(struct platform_device *pdev)
pm_runtime_no_callbacks(&pdev->dev);
pm_runtime_enable(&pdev->dev);
+ pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (!IS_ERR(pinctrl)) {
+ struct pinctrl_state *state;
+
+ state = pinctrl_lookup_state(pinctrl, "enabled");
+ if (!IS_ERR(state))
+ pinctrl_select_state(pinctrl, state);
+ }
+
return 0;
disable_device:
diff --git a/drivers/usb/chipidea/usbmisc_imx.c b/drivers/usb/chipidea/usbmisc_imx.c
index 588bae8eef5e..e29c5aa51b07 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -145,6 +145,11 @@ static int usbmisc_imx6q_init(struct device *dev)
spin_unlock_irqrestore(&usbmisc->lock, flags);
}
+ if (usbdev->index == 2 || usbdev->index == 3) {
+ writel(0x00003000, usbmisc->base + usbdev->index * 4);
+ writel(0x80001842, usbmisc->base + 0x8 + usbdev->index * 4);
+ }
+
return 0;
}
--
1.8.5.2
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
* imx6: usbhc2/3 and HSIC
From: Christian Gmeiner @ 2014-01-27 9:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi all...
does anyone used the usbhc2 or usbhc3 in HSIC mode? I am trying my
luck but I do not
get it to work. Is there anything special I need to take care of?
thanks
--
Christian Gmeiner, MSc
^ permalink raw reply
* [PATCH 2/4] ARM: dts: cm-fx6: add SATA support
From: Igor Grinberg @ 2014-01-27 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127073754.GB4765@S2101-09.ap.freescale.net>
On 01/27/14 09:37, Shawn Guo wrote:
> On Tue, Jan 21, 2014 at 06:13:30PM +0200, Igor Grinberg wrote:
>> Enable SATA on cm-fx6.
>>
>> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
>> ---
>> arch/arm/boot/dts/imx6q-cm-fx6.dts | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
>> index 94cc6b5..07f90a5 100644
>> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
>> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
>> @@ -69,3 +69,7 @@
>> pinctrl-0 = <&pinctrl_uart4>;
>> status = "okay";
>> };
>> +
>> +&sata {
>> + status = "okay";
>> +};
>
> Please sort these labeled nodes alphabetically.
Ok.
I'll wait for the "pingrp macros" to settle down and resend.
Thanks!
--
Regards,
Igor.
^ permalink raw reply
* [PATCH 0/4] add a TDA998x CODEC
From: Jean-Francois Moine @ 2014-01-27 9:04 UTC (permalink / raw)
To: linux-arm-kernel
The TDA998x HDMI transmitter accepts audio input from either I2S or S/PDIF.
Theses inputs have different intrinsic constraints and these constraints
may be modified by the audio parameters of the connected video device.
The choice of I2S or S/PDIF may be the done by the user or by automatic
processing (DPCM?) at each audio starting time. This asks for a dynamic
audio input switch in the HDMI driver.
This patch series implements the TDA998x specific CODEC.
A simple function call mechanism is used for exchanges between the
CODEC and the HDMI driver.
Jean-Francois Moine (4):
drm/i2c: tda998x: add a function for dynamic audio input switch
ASoC: tda998x: add a codec driver for TDA998x
ASoC: tda998x: add DT documentation
ASoC: tda998x: adjust the audio hw parameters from EDID
.../devicetree/bindings/sound/tda998x.txt | 14 +
drivers/gpu/drm/i2c/tda998x_drv.c | 58 +++-
include/drm/i2c/tda998x.h | 8 +-
sound/soc/codecs/Kconfig | 7 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/tda998x.c | 304 +++++++++++++++++++++
6 files changed, 390 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/tda998x.txt
create mode 100644 sound/soc/codecs/tda998x.c
--
1.8.5.3
^ permalink raw reply
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Chen-Yu Tsai @ 2014-01-27 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E61C28.1020207@ti.com>
Hi,
On Mon, Jan 27, 2014 at 4:43 PM, Jyri Sarha <jsarha@ti.com> wrote:
> On 01/24/2014 07:35 PM, Fabio Estevam wrote:
>>
>> On Mon, Jan 20, 2014 at 2:48 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>
>>> So far so good. Now, what about this external oscillator which has its
>>> own separate power control. My immediate thought is that this can be
>>> specified via card_ext_clock - I would simply need to declare a
>>> fixed-rate
>>> clock with either a regulator (power switch) controlled via a gpio (which
>>> would probably be closer to the hardware) or a gpio as an enable... ah,
>>> that requires me to write a common clock driver for that bit since this
>>> is currently not modelled by CCF...
>>
>>
>> Jiry Sarha posted a gpio controlled clock proposal:
>> http://www.spinics.net/lists/devicetree/msg16651.html
>>
>
> I have not received too much feedback to my patch yet. CCF is a bit new
> territory to me, but I think having a separate stackable clk-gpio would be
> more flexible than having the gpio property implemented in clk-fixed-rate.
Not sure where stacking external clocks would be used, but sounds like a
fixed factor clock? Maybe you should add DT support to that if that's what
you need or have.
> Anyway, I am happy do it either way as long as I can get a gpio -controlled
> clock implementation into the main line.
Cheers,
ChenYu
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx6: edmqmx6: remove wrong gpio in usb_otg_vbus regulator
From: Sascha Hauer @ 2014-01-27 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390419567-2643-3-git-send-email-silvio.fricke@gmail.com>
On Wed, Jan 22, 2014 at 08:39:27PM +0100, Silvio F wrote:
> Signed-off-by: Silvio F <silvio.fricke@gmail.com>
> ---
> arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
> index 6706d1b..de54e46 100644
> --- a/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
> +++ b/arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts
> @@ -46,7 +46,6 @@
> regulator-name = "usb_otg_vbus";
> regulator-min-microvolt = <5000000>;
> regulator-max-microvolt = <5000000>;
> - gpio = <&gpio7 12 0>;
This gpio drives a switch between SoCs USB D+/D- lines and the external
connector, so using a regulator here is the wrong approach. The question
now is: What is the correct approach to make sure the switch is closed
when needed? How does it work now? Is the switch on by reset default?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Jean-Francois Moine @ 2014-01-27 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391274627.git.moinejf@free.fr>
The supported audio parameters are described in the EDID which is
received by the HDMI transmitter from the connected screen.
Use these ones to adjust the audio stream parameters.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 15 ++++++++
include/drm/i2c/tda998x.h | 1 +
sound/soc/codecs/tda998x.c | 79 ++++++++++++++++++++++++++++++++++++++-
3 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 68f0b7b..b833fa5 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -47,6 +47,8 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+ u8 *eld;
};
#define to_tda998x_priv(x) ((struct tda998x_priv *)to_encoder_slave(x)->slave_priv)
@@ -733,6 +735,14 @@ tda998x_configure_audio(struct tda998x_priv *priv,
}
/* tda998x codec interface */
+u8 *tda998x_audio_get_eld(struct i2c_client *client)
+{
+ struct tda998x_priv *priv = i2c_get_clientdata(client);
+
+ return priv->eld;
+}
+EXPORT_SYMBOL_GPL(tda998x_audio_get_eld);
+
void tda998x_audio_update(struct i2c_client *client,
int format,
int port)
@@ -1187,6 +1197,11 @@ tda998x_encoder_get_modes(struct drm_encoder *encoder,
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);
priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid);
+
+ /* keep the EDID as ELD for the audio subsystem */
+ drm_edid_to_eld(connector, edid);
+ priv->eld = connector->eld;
+
kfree(edid);
}
diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
index 7e4806d..99387ae 100644
--- a/include/drm/i2c/tda998x.h
+++ b/include/drm/i2c/tda998x.h
@@ -27,6 +27,7 @@ struct tda998x_encoder_params {
unsigned audio_sample_rate;
};
+u8 *tda998x_audio_get_eld(struct i2c_client *client);
void tda998x_audio_update(struct i2c_client *client,
int format,
int port);
diff --git a/sound/soc/codecs/tda998x.c b/sound/soc/codecs/tda998x.c
index 34d7086..0493163 100644
--- a/sound/soc/codecs/tda998x.c
+++ b/sound/soc/codecs/tda998x.c
@@ -64,10 +64,79 @@ static int tda_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct tda_priv *priv = snd_soc_codec_get_drvdata(dai->codec);
+ u8 *eld = NULL;
+ static unsigned rates_mask[] = {
+ SNDRV_PCM_RATE_32000,
+ SNDRV_PCM_RATE_44100,
+ SNDRV_PCM_RATE_48000,
+ SNDRV_PCM_RATE_88200,
+ SNDRV_PCM_RATE_96000,
+ SNDRV_PCM_RATE_176400,
+ SNDRV_PCM_RATE_192000,
+ };
/* memorize the used DAI */
priv->dai_id = dai->id;
+ /* get the ELD from the tda998x driver */
+ if (!priv->i2c_client)
+ tda_get_encoder(priv);
+ if (priv->i2c_client)
+ eld = tda998x_audio_get_eld(priv->i2c_client);
+
+ /* adjust the hw params from the ELD (EDID) */
+ if (eld) {
+ struct snd_soc_dai_driver *dai_drv = dai->driver;
+ struct snd_soc_pcm_stream *stream = &dai_drv->playback;
+ u8 *sad;
+ int sad_count;
+ unsigned eld_ver, mnl, rates, rate_mask, i;
+ unsigned max_channels, fmt;
+ u64 formats;
+
+ eld_ver = eld[0] >> 3;
+ if (eld_ver != 2 && eld_ver != 31)
+ return 0;
+
+ mnl = eld[4] & 0x1f;
+ if (mnl > 16)
+ return 0;
+
+ sad_count = eld[5] >> 4;
+ sad = eld + 20 + mnl;
+
+ /* Start from the basic audio settings */
+ max_channels = 2;
+ rates = 0;
+ fmt = 0;
+ while (sad_count--) {
+ switch (sad[0] & 0x78) {
+ case 0x08: /* PCM */
+ max_channels = max(max_channels, (sad[0] & 7) + 1u);
+ rates |= sad[1];
+ fmt |= sad[2] & 0x07;
+ break;
+ }
+ sad += 3;
+ }
+
+ for (rate_mask = i = 0; i < ARRAY_SIZE(rates_mask); i++)
+ if (rates & 1 << i)
+ rate_mask |= rates_mask[i];
+ formats = 0;
+ if (fmt & 1)
+ formats |= SNDRV_PCM_FMTBIT_S16_LE;
+ if (fmt & 2)
+ formats |= SNDRV_PCM_FMTBIT_S20_3LE;
+ if (fmt & 4)
+ formats |= SNDRV_PCM_FMTBIT_S24_LE;
+
+ /* change the snd_soc_pcm_stream values of the driver */
+ stream->rates = rate_mask;
+ stream->channels_max = max_channels;
+ stream->formats = formats;
+ }
+
/* start the TDA998x audio */
return tda_start_stop(priv);
}
@@ -182,9 +251,17 @@ static const struct snd_soc_codec_driver soc_codec_tda998x = {
static int tda998x_dev_probe(struct platform_device *pdev)
{
+ struct snd_soc_dai_driver *dai_drv;
+
+ /* copy the DAI driver to a writable area */
+ dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL);
+ if (!dai_drv)
+ return -ENOMEM;
+ memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai));
+
return snd_soc_register_codec(&pdev->dev,
&soc_codec_tda998x,
- tda998x_dai, ARRAY_SIZE(tda998x_dai));
+ dai_drv, ARRAY_SIZE(tda998x_dai));
}
static int tda998x_dev_remove(struct platform_device *pdev)
--
1.9.rc1
^ permalink raw reply related
* [PATCH v2 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Jean-Francois Moine @ 2014-01-27 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391081933.git.moinejf@free.fr>
The supported audio parameters are described in the EDID which is
received by the HDMI transmitter from the connected screen.
Use these ones to adjust the audio stream parameters.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
drivers/gpu/drm/i2c/tda998x_drv.c | 15 ++++++++
include/drm/i2c/tda998x.h | 1 +
sound/soc/codecs/tda998x.c | 79 ++++++++++++++++++++++++++++++++++++++-
3 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
index 2643be4..92cbc40 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -46,6 +46,8 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+ u8 *eld;
};
#define to_tda998x_priv(x) ((struct tda998x_priv *)to_encoder_slave(x)->slave_priv)
@@ -732,6 +734,14 @@ tda998x_configure_audio(struct tda998x_priv *priv,
}
/* tda998x codec interface */
+u8 *tda998x_audio_get_eld(struct i2c_client *client)
+{
+ struct tda998x_priv *priv = i2c_get_clientdata(client);
+
+ return priv->eld;
+}
+EXPORT_SYMBOL_GPL(tda998x_audio_get_eld);
+
void tda998x_audio_update(struct i2c_client *client,
int format,
int port)
@@ -1186,6 +1196,11 @@ tda998x_encoder_get_modes(struct drm_encoder *encoder,
drm_mode_connector_update_edid_property(connector, edid);
n = drm_add_edid_modes(connector, edid);
priv->is_hdmi_sink = drm_detect_hdmi_monitor(edid);
+
+ /* keep the EDID as ELD for the audio subsystem */
+ drm_edid_to_eld(connector, edid);
+ priv->eld = connector->eld;
+
kfree(edid);
}
diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
index 7e4806d..99387ae 100644
--- a/include/drm/i2c/tda998x.h
+++ b/include/drm/i2c/tda998x.h
@@ -27,6 +27,7 @@ struct tda998x_encoder_params {
unsigned audio_sample_rate;
};
+u8 *tda998x_audio_get_eld(struct i2c_client *client);
void tda998x_audio_update(struct i2c_client *client,
int format,
int port);
diff --git a/sound/soc/codecs/tda998x.c b/sound/soc/codecs/tda998x.c
index 585cdb6..7f21749 100644
--- a/sound/soc/codecs/tda998x.c
+++ b/sound/soc/codecs/tda998x.c
@@ -84,10 +84,79 @@ static int tda_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct tda_priv *priv = snd_soc_codec_get_drvdata(dai->codec);
+ u8 *eld = NULL;
+ static unsigned rates_mask[] = {
+ SNDRV_PCM_RATE_32000,
+ SNDRV_PCM_RATE_44100,
+ SNDRV_PCM_RATE_48000,
+ SNDRV_PCM_RATE_88200,
+ SNDRV_PCM_RATE_96000,
+ SNDRV_PCM_RATE_176400,
+ SNDRV_PCM_RATE_192000,
+ };
/* memorize the used DAI */
priv->dai_id = dai->id;
+ /* get the ELD from the tda998x driver */
+ if (!priv->i2c_client)
+ tda_get_encoder(priv);
+ if (priv->i2c_client)
+ eld = tda998x_audio_get_eld(priv->i2c_client);
+
+ /* adjust the hw params from the ELD (EDID) */
+ if (eld) {
+ struct snd_soc_dai_driver *dai_drv = dai->driver;
+ struct snd_soc_pcm_stream *stream = &dai_drv->playback;
+ u8 *sad;
+ int sad_count;
+ unsigned eld_ver, mnl, rates, rate_mask, i;
+ unsigned max_channels, fmt;
+ u64 formats;
+
+ eld_ver = eld[0] >> 3;
+ if (eld_ver != 2 && eld_ver != 31)
+ return 0;
+
+ mnl = eld[4] & 0x1f;
+ if (mnl > 16)
+ return 0;
+
+ sad_count = eld[5] >> 4;
+ sad = eld + 20 + mnl;
+
+ /* Start from the basic audio settings */
+ max_channels = 2;
+ rates = 0;
+ fmt = 0;
+ while (sad_count--) {
+ switch (sad[0] & 0x78) {
+ case 0x08: /* PCM */
+ max_channels = max(max_channels, (sad[0] & 7) + 1u);
+ rates |= sad[1];
+ fmt |= sad[2] & 0x07;
+ break;
+ }
+ sad += 3;
+ }
+
+ for (rate_mask = i = 0; i < ARRAY_SIZE(rates_mask); i++)
+ if (rates & 1 << i)
+ rate_mask |= rates_mask[i];
+ formats = 0;
+ if (fmt & 1)
+ formats |= SNDRV_PCM_FMTBIT_S16_LE;
+ if (fmt & 2)
+ formats |= SNDRV_PCM_FMTBIT_S20_3LE;
+ if (fmt & 4)
+ formats |= SNDRV_PCM_FMTBIT_S24_LE;
+
+ /* change the snd_soc_pcm_stream values of the driver */
+ stream->rates = rate_mask;
+ stream->channels_max = max_channels;
+ stream->formats = formats;
+ }
+
/* start the TDA998x audio */
return tda_start_stop(priv);
}
@@ -203,9 +272,17 @@ static const struct snd_soc_codec_driver soc_codec_tda998x = {
static int tda998x_dev_probe(struct platform_device *pdev)
{
+ struct snd_soc_dai_driver *dai_drv;
+
+ /* copy the DAI driver to a writable area */
+ dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL);
+ if (!dai_drv)
+ return -ENOMEM;
+ memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai));
+
return snd_soc_register_codec(&pdev->dev,
&soc_codec_tda998x,
- tda998x_dai, ARRAY_SIZE(tda998x_dai));
+ dai_drv, ARRAY_SIZE(tda998x_dai));
}
static int tda998x_dev_remove(struct platform_device *pdev)
--
1.9.rc1
^ permalink raw reply related
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