* [PATCH v4 1/3] ASoC: sun4i-codec: rename sun4i_codec_widgets for consistency
From: Danny Milosavljevic @ 2016-09-15 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915163630.18026-1-dannym@scratchpost.org>
ASoC: sun4i-codec: Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
consistency with the struct field name.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 0e19c50..c2c0583 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
-static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
+static const struct snd_kcontrol_new sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
sun4i_codec_pa_volume_scale),
@@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
static struct snd_soc_codec_driver sun4i_codec_codec = {
.component_driver = {
- .controls = sun4i_codec_widgets,
- .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
+ .controls = sun4i_codec_controls,
+ .num_controls = ARRAY_SIZE(sun4i_codec_controls),
.dapm_widgets = sun4i_codec_codec_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
.dapm_routes = sun4i_codec_codec_dapm_routes,
^ permalink raw reply related
* [PATCH v4 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i
From: Danny Milosavljevic @ 2016-09-15 16:36 UTC (permalink / raw)
To: linux-arm-kernel
ASoC: sun4i-codec: Introduce mechanism to detect sun7i and provide a
different regmap different compared to sun4i Allwinner A10.
The controls will be extended in a forthcoming patch - it is necessary
to distinguish between sun4i and sun7i controls because they have different
registers.
Renamed SUN4I_CODEC_AC_SYS_VERI to SUN7I_CODEC_AC_DAC_CAL and renamed
SUN4I_CODEC_AC_MIC_PHONE_CAL to SUN7I_CODEC_AC_MIC_PHONE_CAL because these
are actually not present on Allwinner A10.
Handle quirks by regmap config and codec and select the correct quirks
automatically.
Danny Milosavljevic (3):
ASoC: sun4i-codec: rename "sun4i_codec_widgets" to
"sun4i_codec_controls" for consistency with the struct field name.
ASoC: rename "SUN4I_CODEC_SYS_VERI" to "SUN7I_CODEC_AC_DAC_CAL";
rename "SUN4I_CODEC_AC_MIC_PHONE_CAL" to
"SUN7I_CODEC_AC_MIC_PHONE_CAL".
ASoC: sun4i-codec: Add custom regmap configs for the A10 and A20
variants.
sound/soc/sunxi/sun4i-codec.c | 45 ++++++++++++++++++++++++++++++++++---------
1 file changed, 36 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH] arm64: kprobe: Always clear pstate.D in breakpoint exception handler
From: Pratyush Anand @ 2016-09-15 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915161828.GH3380@arm.com>
On Thu, Sep 15, 2016 at 9:48 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Sep 15, 2016 at 09:45:09PM +0530, Pratyush Anand wrote:
>> On Wed, Aug 24, 2016 at 3:36 PM, Pratyush Anand <panand@redhat.com> wrote:
>> > On 23/08/2016:04:33:08 PM, Sandeepa Prabhu wrote:
>> >> Thanks for the fix, feel free to add my ACK as well. Has it been tested on
>> >> guest kernel?
>> >
>> > have not tested on guest kernel.Will do.
>>
>> I tested it with guest kernel, and it worked there too :-).
>>
>> @Catalin: any more comment for this patch? If not, then may be you can take it.
>
> I already queued this on the arm64 for-next/core branch.
>
Thanks Will :-)
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Vinod Koul @ 2016-09-15 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160810173710.GK9681@localhost>
On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> > Hi,
> >
> > This series tries to solve the problem with DMA with device registers
> > (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> > recent patch '9575632 (dmaengine: make slave address physical)'
> > clarifies that DMA slave address provided by clients is the physical
> > address. This puts the task of mapping the DMA slave address from a
> > phys_addr_t to a dma_addr_t on the DMA engine.
> >
> > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > the same and no special care is needed. However if you have a IOMMU you
> > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > like this.
> >
> > This series is based on top of v4.8-rc1. And I'm hoping to be able to collect a
> > Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> > able to take the whole series through the dmaengine tree. If this is not the
> > best route I'm more then happy to do it another way.
> >
> > It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> > ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> > /dev/mmcblk1, i2c and the serial console which are devices behind the
> > iommu.
>
> As I said in last one, the dmaengine parts look fine to me. But to go thru
> dmaengine tree I would need ACK on non dmaengine patches.
I havent heard back from this one and I am inclined to merge this one now.
If anyone has any objects, please speak up now...
Also ACKs welcome...
--
~Vinod
^ permalink raw reply
* [PATCH] ARM: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Vinod Koul @ 2016-09-15 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2fa402bf-0e3f-0495-41ca-7a3c89eaa2e1@samsung.com>
On Thu, Sep 15, 2016 at 11:05:12AM +0200, Sylwester Nawrocki wrote:
> On 09/14/2016 08:29 PM, Sam Van Den Berge wrote:
> > +static const struct dma_slave_map s3c2440_dma_slave_map[] = {
> ...
> > + { "3c2440-sdi", "rx", (void *)DMACH_SDI },
> > + { "3c2440-sdi", "tx", (void *)DMACH_SDI },
>
> The device names seem misspelled here, and looking at what
> drivers/mmc/host/s3cmci.c driver does we need just a single common
> entry for rx and tx
>
> { "s3c2440-sdi", "rx-tx", (void *)DMACH_SDI },
>
> With this fixed feel free to add
And please change the title to dmaengine and NOT arm... I was about ti skip
this!
--
~Vinod
^ permalink raw reply
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Mark Rutland @ 2016-09-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473788797-10879-1-git-send-email-catalin.marinas@arm.com>
Hi Catalin,
On Tue, Sep 13, 2016 at 06:46:30PM +0100, Catalin Marinas wrote:
> This is the third version of the arm64 PAN emulation using TTBR0_EL1
> switching. The series has not yet included the alternative nop patches
> from Mark Rutland, nor the empty_zero_page from Ard B. This will be done
> in a subsequent version once 4.9-rc1 is out (which will include Mark's
> alternative nop patches).
> arch/arm64/Kconfig | 8 ++
> arch/arm64/include/asm/assembler.h | 33 +++++++
> arch/arm64/include/asm/cpufeature.h | 6 ++
> arch/arm64/include/asm/efi.h | 26 ++++-
> arch/arm64/include/asm/futex.h | 14 +--
> arch/arm64/include/asm/kernel-pgtable.h | 7 ++
> arch/arm64/include/asm/mmu_context.h | 51 +++++++---
> arch/arm64/include/asm/ptrace.h | 2 +
> arch/arm64/include/asm/thread_info.h | 3 +
> arch/arm64/include/asm/uaccess.h | 163 ++++++++++++++++++++++++++++++--
> arch/arm64/kernel/armv8_deprecated.c | 10 +-
> arch/arm64/kernel/asm-offsets.c | 3 +
> arch/arm64/kernel/cpufeature.c | 1 +
> arch/arm64/kernel/entry.S | 71 +++++++++++++-
> arch/arm64/kernel/head.S | 6 +-
> arch/arm64/kernel/setup.c | 9 ++
> arch/arm64/kernel/vmlinux.lds.S | 5 +
> arch/arm64/lib/clear_user.S | 8 +-
> arch/arm64/lib/copy_from_user.S | 8 +-
> arch/arm64/lib/copy_in_user.S | 8 +-
> arch/arm64/lib/copy_to_user.S | 8 +-
> arch/arm64/mm/context.c | 7 +-
> arch/arm64/mm/fault.c | 22 +++--
> arch/arm64/mm/proc.S | 11 +--
> arch/arm64/xen/hypercall.S | 19 ++++
> 25 files changed, 428 insertions(+), 81 deletions(-)
I don't seee traps.c there. Don't we need to fix up do_sysinstr() (which
performs raw cache maintenance ops on __user addresses) with
uaccess_{enable,disable}_not_uao()?
Likewise, how do we handle __flush_cache_user_range and
flush_icache_range? Some callers (e.g. __do_compat_cache_op) pass in
__user addresses.
I hope we have some tests lying around for those. ;)
Thanks,
Mark.
^ permalink raw reply
* [PATCH v9 00/19] Add support for FDMA DMA controller and slim core rproc found on STi chipsets
From: Vinod Koul @ 2016-09-15 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914130739.GE13920@localhost>
On Wed, Sep 14, 2016 at 06:37:40PM +0530, Vinod Koul wrote:
> On Tue, Sep 13, 2016 at 11:06:16AM -0700, Bjorn Andersson wrote:
> > > I hate to send a ping,
> >
> > Sorry about that.
> >
> > > but do you think we can merge this fdma series? It has gone
> > > through quite a few review rounds now.
> > >
> >
> > I think the remoteproc part looks good.
>
> yeah I was waiting for ack on other patches. But looks like at least
> remoteproc ones have it
>
>
> > Vinod, I don't have any changes queued in remoteproc that should cause
> > merge issues. If you want to you could take the remoteproc patch
> > through your tree.
>
> I rechecked the dma part, they look good to me, so I should be able to apply
> these. I will wait a day for ack/nacks. It is the time to speak up :)
And I have applied thru 9th patch. Others are applied by Patrice.
Btw you should send drm ones to drm folks separately and not in this
series..
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH] arm64: kprobe: Always clear pstate.D in breakpoint exception handler
From: Will Deacon @ 2016-09-15 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHB_Guods-iED+tOLeJ9XCWDvAVoButwz2XWSiP+eMYDzFhfyQ@mail.gmail.com>
On Thu, Sep 15, 2016 at 09:45:09PM +0530, Pratyush Anand wrote:
> On Wed, Aug 24, 2016 at 3:36 PM, Pratyush Anand <panand@redhat.com> wrote:
> > On 23/08/2016:04:33:08 PM, Sandeepa Prabhu wrote:
> >> Thanks for the fix, feel free to add my ACK as well. Has it been tested on
> >> guest kernel?
> >
> > have not tested on guest kernel.Will do.
>
> I tested it with guest kernel, and it worked there too :-).
>
> @Catalin: any more comment for this patch? If not, then may be you can take it.
I already queued this on the arm64 for-next/core branch.
Will
^ permalink raw reply
* [PATCH] arm64: kprobe: Always clear pstate.D in breakpoint exception handler
From: Pratyush Anand @ 2016-09-15 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160824100644.GB4408@localhost.localdomain>
Hi Sandeepa,
On Wed, Aug 24, 2016 at 3:36 PM, Pratyush Anand <panand@redhat.com> wrote:
> Hi Sandeepa,
>
> Thanks for the review.
>
> On 23/08/2016:04:33:08 PM, Sandeepa Prabhu wrote:
>> Thanks for the fix, feel free to add my ACK as well. Has it been tested on
>> guest kernel?
>
> have not tested on guest kernel.Will do.
I tested it with guest kernel, and it worked there too :-).
@Catalin: any more comment for this patch? If not, then may be you can take it.
~Pratyush
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Bryan O'Donoghue @ 2016-09-15 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915154736.GA19214@leverpostej>
On Thu, 2016-09-15 at 16:47 +0100, Mark Rutland wrote:
> On?
> I can't say this any more explicitly:
>
> ****************************************************
> * The DT *cannot* know anything about get_cycles() *
> ****************************************************
>
> It's no more complex than that.
Sure think Mark I understand your point.
I think to satisfy your objection the most sensible change to make is
using arch_timer_get_rate() compared to a desired rate of 19200000.
---
bod
^ permalink raw reply
* [PATCH BUGFIX] mtd: nand: mxc: fix obiwan error in mxc_nand_v[12]_ooblayout_free() functions
From: Boris Brezillon @ 2016-09-15 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473432251-24728-1-git-send-email-LW@KARO-electronics.de>
Hi Lothar,
On Fri, 9 Sep 2016 16:44:11 +0200
Lothar Wa?mann <LW@KARO-electronics.de> wrote:
> commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> introduced a regression accessing the OOB area from the mxc_nand
> driver due to an Obiwan error in the mxc_nand_v[12]_ooblayout_free()
> functions. They report a bogus oobregion { 64, 7 } which leads to
> errors accessing bogus data when reading the oob area.
>
> Prior to the commit the mtd-oobtest module could be run without any
> errors. With the offending commit, this test fails with results like:
> |Running mtd-oobtest
> |
> |=================================================
> |mtd_oobtest: MTD device: 5
> |mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 64
> |mtd_test: scanning for bad eraseblocks
> |mtd_test: scanned 4 eraseblocks, 0 are bad
> |mtd_oobtest: test 1 of 5
> |mtd_oobtest: writing OOBs of whole device
> |mtd_oobtest: written up to eraseblock 0
> |mtd_oobtest: written 4 eraseblocks
> |mtd_oobtest: verifying all eraseblocks
> |mtd_oobtest: error @addr[0x0:0x19] 0x9a -> 0x78 diff 0xe2
> |mtd_oobtest: error @addr[0x0:0x1a] 0xcc -> 0x0 diff 0xcc
> |mtd_oobtest: error @addr[0x0:0x1b] 0xe0 -> 0x85 diff 0x65
> |mtd_oobtest: error @addr[0x0:0x1c] 0x60 -> 0x62 diff 0x2
> |mtd_oobtest: error @addr[0x0:0x1d] 0x69 -> 0x45 diff 0x2c
> |mtd_oobtest: error @addr[0x0:0x1e] 0xcd -> 0xa0 diff 0x6d
> |mtd_oobtest: error @addr[0x0:0x1f] 0xf2 -> 0x60 diff 0x92
> |mtd_oobtest: error: verify failed at 0x0
> [...]
>
> Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> ---
> drivers/mtd/nand/mxc_nand.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> index 5173fad..fdee907 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -893,7 +893,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
> {
> struct nand_chip *nand_chip = mtd_to_nand(mtd);
>
> - if (section > nand_chip->ecc.steps)
> + if (section >= nand_chip->ecc.steps)
> return -ERANGE;
Hm, looking at the commit you're pointing to, it seems that this test
is correct (we have X + 1 free sections, where X is the number of ECC
steps).
>
> if (!section) {
> @@ -943,7 +943,7 @@ static int mxc_v2_ooblayout_free(struct mtd_info *mtd, int section,
> struct nand_chip *nand_chip = mtd_to_nand(mtd);
> int stepsize = nand_chip->ecc.bytes == 9 ? 16 : 26;
>
> - if (section > nand_chip->ecc.steps)
> + if (section >= nand_chip->ecc.steps)
> return -ERANGE;
Yep, this one is a real bug.
>
> if (!section) {
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Mark Rutland @ 2016-09-15 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473954000.4035.5.camel@nexus-software.ie>
On Thu, Sep 15, 2016 at 04:40:00PM +0100, Bryan O'Donoghue wrote:
> On Thu, 2016-09-15 at 13:46 +0100, Mark Rutland wrote:
> > On Thu, Sep 15, 2016 at 12:48:08PM +0100, Bryan O'Donoghue wrote:
> > > On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote:
> > > > For example, you have absolutely no guarantee as to what backs
> > > > get_cycles(). Despite this, the code assumes that get_cycles() is
> > > > backed by something running at the frequency described in a
> > > > "google,greybus-frame-time-counter" node.
> > > >
> > > > Even if this *happens* to match what some piece of arch code
> > > > provides
> > > > today on some platform, it is in no way *guaranteed*.
> > > That's the point though, if you declare "google,greybus-frame-time-
> > > counter" in your platform code - then you can use 'get_cycles()' in
> > > this manner
> > To be clear, *some* properties (and perhaps additional nodes) may
> > need
> > to be in the DT, in order to capture the hardware property or
> > relationship that you are reliant upon.
>
> Sure but on the relevant platform we know?
>
> 1. get_cycles() is derived from an architectured MMIO timer
> 2. What is clocking that timer
>
> So any platform that declares that property must be aware of what its
> doing.
I can't say this any more explicitly:
****************************************************
* The DT *cannot* know anything about get_cycles() *
****************************************************
It's no more complex than that.
Thanks,
Mark.
^ permalink raw reply
* [PATCH] clk: zx: fix pointer case warnings
From: Arnd Bergmann @ 2016-09-15 15:45 UTC (permalink / raw)
To: linux-arm-kernel
The zx296718 clock driver has a creative way of assigning the register
values for each clock, by initializing an __iomem pointer to an
offset and then later adding the base (from ioremap) on top
with a cast to u64. This fail on all 32-bit architectures during
compile testing:
drivers/clk/zte/clk-zx296718.c: In function 'top_clocks_init':
drivers/clk/zte/clk-zx296718.c:554:35: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
zx296718_pll_clk[i].reg_base += (u64)reg_base;
drivers/clk/zte/clk-zx296718.c:579:29: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
drivers/clk/zte/clk-zx296718.c:592:31: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
It would be nice to avoid all the casts, but I decided to simply
shut up the warnings by changing the type from u64 to uintptr_t,
which does the right thing in practice.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: ca0233285a93 ("clk: zx: register ZX296718 clocks")
---
drivers/clk/zte/clk-zx296718.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/zte/clk-zx296718.c b/drivers/clk/zte/clk-zx296718.c
index 025e324fab5c..b34402d0cd69 100644
--- a/drivers/clk/zte/clk-zx296718.c
+++ b/drivers/clk/zte/clk-zx296718.c
@@ -551,7 +551,7 @@ static int __init top_clocks_init(struct device_node *np)
}
for (i = 0; i < ARRAY_SIZE(zx296718_pll_clk); i++) {
- zx296718_pll_clk[i].reg_base += (u64)reg_base;
+ zx296718_pll_clk[i].reg_base += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &zx296718_pll_clk[i].hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -576,7 +576,7 @@ static int __init top_clocks_init(struct device_node *np)
top_hw_onecell_data.hws[top_mux_clk[i].id] =
&top_mux_clk[i].mux.hw;
- top_mux_clk[i].mux.reg += (u64)reg_base;
+ top_mux_clk[i].mux.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &top_mux_clk[i].mux.hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -589,7 +589,7 @@ static int __init top_clocks_init(struct device_node *np)
top_hw_onecell_data.hws[top_gate_clk[i].id] =
&top_gate_clk[i].gate.hw;
- top_gate_clk[i].gate.reg += (u64)reg_base;
+ top_gate_clk[i].gate.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &top_gate_clk[i].gate.hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -602,7 +602,7 @@ static int __init top_clocks_init(struct device_node *np)
top_hw_onecell_data.hws[top_div_clk[i].id] =
&top_div_clk[i].div.hw;
- top_div_clk[i].div.reg += (u64)reg_base;
+ top_div_clk[i].div.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &top_div_clk[i].div.hw);
if (ret) {
pr_warn("top clk %s init error!\n",
@@ -742,7 +742,7 @@ static int __init lsp0_clocks_init(struct device_node *np)
lsp0_hw_onecell_data.hws[lsp0_mux_clk[i].id] =
&lsp0_mux_clk[i].mux.hw;
- lsp0_mux_clk[i].mux.reg += (u64)reg_base;
+ lsp0_mux_clk[i].mux.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp0_mux_clk[i].mux.hw);
if (ret) {
pr_warn("lsp0 clk %s init error!\n",
@@ -755,7 +755,7 @@ static int __init lsp0_clocks_init(struct device_node *np)
lsp0_hw_onecell_data.hws[lsp0_gate_clk[i].id] =
&lsp0_gate_clk[i].gate.hw;
- lsp0_gate_clk[i].gate.reg += (u64)reg_base;
+ lsp0_gate_clk[i].gate.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp0_gate_clk[i].gate.hw);
if (ret) {
pr_warn("lsp0 clk %s init error!\n",
@@ -768,7 +768,7 @@ static int __init lsp0_clocks_init(struct device_node *np)
lsp0_hw_onecell_data.hws[lsp0_div_clk[i].id] =
&lsp0_div_clk[i].div.hw;
- lsp0_div_clk[i].div.reg += (u64)reg_base;
+ lsp0_div_clk[i].div.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp0_div_clk[i].div.hw);
if (ret) {
pr_warn("lsp0 clk %s init error!\n",
@@ -847,7 +847,7 @@ static int __init lsp1_clocks_init(struct device_node *np)
lsp1_hw_onecell_data.hws[lsp1_mux_clk[i].id] =
&lsp0_mux_clk[i].mux.hw;
- lsp1_mux_clk[i].mux.reg += (u64)reg_base;
+ lsp1_mux_clk[i].mux.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp1_mux_clk[i].mux.hw);
if (ret) {
pr_warn("lsp1 clk %s init error!\n",
@@ -860,7 +860,7 @@ static int __init lsp1_clocks_init(struct device_node *np)
lsp1_hw_onecell_data.hws[lsp1_gate_clk[i].id] =
&lsp1_gate_clk[i].gate.hw;
- lsp1_gate_clk[i].gate.reg += (u64)reg_base;
+ lsp1_gate_clk[i].gate.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp1_gate_clk[i].gate.hw);
if (ret) {
pr_warn("lsp1 clk %s init error!\n",
@@ -873,7 +873,7 @@ static int __init lsp1_clocks_init(struct device_node *np)
lsp1_hw_onecell_data.hws[lsp1_div_clk[i].id] =
&lsp1_div_clk[i].div.hw;
- lsp1_div_clk[i].div.reg += (u64)reg_base;
+ lsp1_div_clk[i].div.reg += (uintptr_t)reg_base;
ret = clk_hw_register(NULL, &lsp1_div_clk[i].div.hw);
if (ret) {
pr_warn("lsp1 clk %s init error!\n",
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2 v3] bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
From: Vinod Koul @ 2016-09-15 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915053731.25263-1-sr@denx.de>
On Thu, Sep 15, 2016 at 07:37:30AM +0200, Stefan Roese wrote:
> This patch provides a stub function for mvebu_mbus_get_io_win_info(),
> which will be used for all non-Orion (ARM32 MVEBU) platforms for
> compile test coverage.
>
> On such platforms this function will return an error so that drivers
> might detect a potential problem.
Applied both,
Thanks
--
~Vinod
^ permalink raw reply
* [PATCH] MMC: meson: remove unused variable
From: Arnd Bergmann @ 2016-09-15 15:43 UTC (permalink / raw)
To: linux-arm-kernel
The newly added meson mmc driver causes a build warning from an unused
variable:
drivers/mmc/host/meson-gxbb.c: In function 'meson_mmc_request_done':
drivers/mmc/host/meson-gxbb.c:411:22: error: unused variable 'cmd' [-Werror=unused-variable]
This removes the variable.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4b331229dda9 ("MMC: meson: initial support for GXBB platforms")
---
drivers/mmc/host/meson-gxbb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/meson-gxbb.c b/drivers/mmc/host/meson-gxbb.c
index c73c62178764..193d343d0afe 100644
--- a/drivers/mmc/host/meson-gxbb.c
+++ b/drivers/mmc/host/meson-gxbb.c
@@ -408,7 +408,6 @@ static void meson_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
static int meson_mmc_request_done(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct meson_host *host = mmc_priv(mmc);
- struct mmc_command *cmd = host->cmd;
WARN_ON(host->mrq != mrq);
--
2.9.0
^ permalink raw reply related
* next-20160915 build: 2 failures 16 warnings (next-20160915)
From: Mark Brown @ 2016-09-15 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1bkV4u-0004AY-TY@optimist>
On Thu, Sep 15, 2016 at 12:43:41PM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build both arm and arm64 allmodconfigs due to:
> arm64-allmodconfig
> ERROR: "musb_root_disconnect" [drivers/usb/musb/sunxi.ko] undefined!
> arm-allmodconfig
> ERROR: "musb_root_disconnect" [drivers/usb/musb/sunxi.ko] undefined!
due to 7cba17ec9adc8cf (musb: sunxi: Add support for platform_set_mode)
which adds a call to that non-exported function to a module.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160915/0d4087c8/attachment.sig>
^ permalink raw reply
* [GIT PULL] Greybus driver subsystem for 4.9-rc1
From: Bryan O'Donoghue @ 2016-09-15 15:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915124601.GA9316@leverpostej>
On Thu, 2016-09-15 at 13:46 +0100, Mark Rutland wrote:
> On Thu, Sep 15, 2016 at 12:48:08PM +0100, Bryan O'Donoghue wrote:
> >
> > On Thu, 2016-09-15 at 12:20 +0100, Mark Rutland wrote:
> > >
> > > For example, you have absolutely no guarantee as to what backs
> > > get_cycles(). Despite this, the code assumes that get_cycles() is
> > > backed by something running at the frequency described in a
> > > "google,greybus-frame-time-counter" node.
> > >
> > > Even if this *happens* to match what some piece of arch code
> > > provides
> > > today on some platform, it is in no way *guaranteed*.
> > That's the point though, if you declare "google,greybus-frame-time-
> > counter" in your platform code - then you can use 'get_cycles()' in
> > this manner
> To be clear, *some* properties (and perhaps additional nodes) may
> need
> to be in the DT, in order to capture the hardware property or
> relationship that you are reliant upon.
Sure but on the relevant platform we know?
1. get_cycles() is derived from an architectured MMIO timer
2. What is clocking that timer
So any platform that declares that property must be aware of what its
doing.
For clarity this is the alternative to reading another register
directly bypassing get_cycles().
> >
> > >
> > > Without a higher-level view of what you're trying to achieve,
> > > it's
> > > not clear to me whether get_cycles() is the right interface.
> > I appreciate that.
> Until that's clarified, we won't make any progress here.
Let's see. We're synchronizing a set of distributed timers via a GPIO
pulse. Each processor on the system has at least one timer block
directly driven by the refclk at 19.2MHz?or a PLL driven by refclk at 19.2MHz
FrameTime is a 64 bit free-running counter running @19.2MHz that is
used as a common source of reference for events. On the MSM side this
implies reading one of the timers driven by that refclk directly.
The choices on MSM8994 to access one of those timer blocks are
1. Read the register directly as is done in earlier patches or
2. Read get_cycles() as is done in later patches.
It's no more complex than that.
---
bod
^ permalink raw reply
* [RFC PATCH v2 11/11] irqchip: mbigen: promote mbigen init
From: Marc Zyngier @ 2016-09-15 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473862879-7769-12-git-send-email-guohanjun@huawei.com>
On 14/09/16 15:21, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> mbigen is an irqchip and it needs to be probed before
> devices, same logic is used for SMMU and etc., let's
> use arch_initcall instead of platform init for mbigen.
>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ma Jun <majun258@huawei.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/irqchip/irq-mbigen.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
> index ca6add1..3a33de6 100644
> --- a/drivers/irqchip/irq-mbigen.c
> +++ b/drivers/irqchip/irq-mbigen.c
> @@ -374,7 +374,11 @@ static struct platform_driver mbigen_platform_driver = {
> .probe = mbigen_device_probe,
> };
>
> -module_platform_driver(mbigen_platform_driver);
> +static __init int mbigen_init(void)
> +{
> + return platform_driver_register(&mbigen_platform_driver);
> +}
> +arch_initcall(mbigen_init);
>
> MODULE_AUTHOR("Jun Ma <majun258@huawei.com>");
> MODULE_AUTHOR("Yun Wu <wuyun.wu@huawei.com>");
>
I've already NACKed such a patch in the past, and I will carry on
NACKing it until all the other avenues (like properly tracking device
dependencies) have been explored and have been proven not to be fit for
purpose.
Rafael had proposed something around this subject last year, and I've
been repeatedly advising you to work with him and others to make it
happen. You can choose to ignore this advise, but that doesn't make this
patch an acceptable approach.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 1/3] ASoC: sun4i-codec: rename "sun4i_codec_widgets" to "sun4i_codec_controls" for consistency with the struct field name.
From: Chen-Yu Tsai @ 2016-09-15 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-2-dannym@scratchpost.org>
On Thu, Sep 15, 2016 at 10:39 PM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
> ASoC: sun4i-codec: rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
> consistency with the struct field name.
Subject is way too long. The commit messages should be straight
forward sentences,
not in the format of patch subjects.
Subject could read "ASoC: sun4i-codec: rename sun4i_codec_widgets for
consistency".
Then in the commit message you could elaborate on consistency with what, as you
did here in the subject.
Regards
ChenYu
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 0e19c50..c2c0583 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
>
> static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
>
> -static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
> +static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
> SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
> sun4i_codec_pa_volume_scale),
> @@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
>
> static struct snd_soc_codec_driver sun4i_codec_codec = {
> .component_driver = {
> - .controls = sun4i_codec_widgets,
> - .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
> + .controls = sun4i_codec_controls,
> + .num_controls = ARRAY_SIZE(sun4i_codec_controls),
> .dapm_widgets = sun4i_codec_codec_dapm_widgets,
> .num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
> .dapm_routes = sun4i_codec_codec_dapm_routes,
^ permalink raw reply
* [PATCH v3 3/3] ASoC: sun4i-codec: Add custom regmap configs for the A10 and A20 variants.
From: Chen-Yu Tsai @ 2016-09-15 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-4-dannym@scratchpost.org>
On Thu, Sep 15, 2016 at 10:39 PM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
> ASoC: sun4i-codec: Add custom regmap configs for the A10 and A20 variants.
The commit message should be a straight forward description about what
the patch does and why you did it, not a direct copy of the subject.
Something along the lines of "The A20 has a few extra registers that
the A10 doesn't have ..." will do for the why.
Regards
ChenYu
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 33 ++++++++++++++++++++++++++++++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 3b53b78..c5d6d84c 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -682,12 +682,37 @@ static const struct regmap_config sun4i_codec_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> + .max_register = SUN4I_CODEC_ADC_RXCNT,
> +};
> +
> +static const struct regmap_config sun7i_codec_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
> };
>
> +struct sun4i_codec_quirks {
> + const struct regmap_config *regmap_config;
> +};
> +
> +static const struct sun4i_codec_quirks sun4i_codec_quirks = {
> + .regmap_config = &sun4i_codec_regmap_config,
> +};
> +
> +static const struct sun4i_codec_quirks sun7i_codec_quirks = {
> + .regmap_config = &sun7i_codec_regmap_config,
> +};
> +
> static const struct of_device_id sun4i_codec_of_match[] = {
> - { .compatible = "allwinner,sun4i-a10-codec" },
> - { .compatible = "allwinner,sun7i-a20-codec" },
> + {
> + .compatible = "allwinner,sun4i-a10-codec",
> + .data = &sun4i_codec_quirks,
> + },
> + {
> + .compatible = "allwinner,sun7i-a20-codec",
> + .data = &sun7i_codec_quirks,
> + },
> {}
> };
> MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
> @@ -760,6 +785,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> {
> struct snd_soc_card *card;
> struct sun4i_codec *scodec;
> + const struct sun4i_codec_quirks *quirks;
> struct resource *res;
> void __iomem *base;
> int ret;
> @@ -777,8 +803,9 @@ static int sun4i_codec_probe(struct platform_device *pdev)
> return PTR_ERR(base);
> }
>
> + quirks = of_device_get_match_data(&pdev->dev);
> scodec->regmap = devm_regmap_init_mmio(&pdev->dev, base,
> - &sun4i_codec_regmap_config);
> + quirks->regmap_config);
> if (IS_ERR(scodec->regmap)) {
> dev_err(&pdev->dev, "Failed to create our regmap\n");
> return PTR_ERR(scodec->regmap);
^ permalink raw reply
* [PATCH v3 2/7] arm64: Factor out TTBR0_EL1 post-update workaround into a specific asm macro
From: Mark Rutland @ 2016-09-15 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473788797-10879-3-git-send-email-catalin.marinas@arm.com>
On Tue, Sep 13, 2016 at 06:46:32PM +0100, Catalin Marinas wrote:
> This patch takes the errata workaround code out of cpu_do_switch_mm into
> a dedicated post_ttbr0_update_workaround macro which will be reused in a
> subsequent patch.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/assembler.h | 17 +++++++++++++++++
> arch/arm64/mm/proc.S | 11 +----------
> 2 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index d5025c69ca81..0a47632787d9 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -350,4 +350,21 @@ alternative_endif
> movk \reg, :abs_g0_nc:\val
> .endm
>
> +/*
> + * Errata workaround post TTBR0_EL1 update.
> + */
> + .macro post_ttbr0_update_workaround
> +#ifdef CONFIG_CAVIUM_ERRATUM_27456
> +alternative_if_not ARM64_WORKAROUND_CAVIUM_27456
> + nop
> + nop
> + nop
> +alternative_else
> + ic iallu
> + dsb nsh
> + isb
> +alternative_endif
> +#endif
> + .endm
> +
> #endif /* __ASM_ASSEMBLER_H */
As a general note, it's unfortunate that we put asm with alternatives in
<asm/assembler.h>, as that's included by <asm/alternative.h>, so we're
relying on things that aren't defined yet, and users have to remember to
include <asm/alternative.h>.
That's already the case for dcache_by_line_op, so I guess that's
something to deal with another day.
Otherwise, this looks good, and I guess this wil be auto-nopped in a
subsqeuent version, so FWIW:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [RFC PATCH v2 05/11] ACPI: platform: setup MSI domain for ACPI based platform device
From: Marc Zyngier @ 2016-09-15 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DAAAAE.6010206@linaro.org>
On 15/09/16 15:05, Hanjun Guo wrote:
> Hi Marc,
>
> Thanks for your review, reply inline.
>
> On 09/14/2016 11:45 PM, Marc Zyngier wrote:
>> On 14/09/16 15:21, Hanjun Guo wrote:
>>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>>
>>> With the platform msi domain created, we can set up the msi domain
>>> for a platform device when it's probed.
>>>
>>> This patch introduces acpi_configure_msi_domain(), which retrieves
>>> the domain from iort and set it to platform device.
>>>
>>> As some platform devices such as an irqchip needs the msi irqdomain
>>> to be the interrupt parent domain, we need to get irqdomain before
>>> platform device is probed.
>>>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Greg KH <gregkh@linuxfoundation.org>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> Cc: Tomasz Nowicki <tn@semihalf.com>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>> drivers/acpi/arm64/iort.c | 5 ++++-
>>> drivers/base/platform-msi.c | 15 ++++++++++++++-
>>> drivers/base/platform.c | 2 ++
>>> include/linux/msi.h | 1 +
>>> 4 files changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>> index 13a1905..bccd3cc 100644
>>> --- a/drivers/acpi/arm64/iort.c
>>> +++ b/drivers/acpi/arm64/iort.c
>>> @@ -478,6 +478,7 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
>>> {
>>> struct fwnode_handle *handle;
>>> int its_id;
>>> + enum irq_domain_bus_token bus_token;
>>>
>>> if (iort_dev_find_its_id(dev, req_id, 0, &its_id))
>>> return NULL;
>>> @@ -486,7 +487,9 @@ struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id)
>>> if (!handle)
>>> return NULL;
>>>
>>> - return irq_find_matching_fwnode(handle, DOMAIN_BUS_PCI_MSI);
>>> + bus_token = dev_is_pci(dev) ?
>>> + DOMAIN_BUS_PCI_MSI : DOMAIN_BUS_PLATFORM_MSI;
>>> + return irq_find_matching_fwnode(handle, bus_token);
>>> }
>>>
>>> static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>>> diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
>>> index 279e539..f6eae18 100644
>>> --- a/drivers/base/platform-msi.c
>>> +++ b/drivers/base/platform-msi.c
>>> @@ -17,8 +17,8 @@
>>> * along with this program. If not, see <http://www.gnu.org/licenses/>.
>>> */
>>>
>>> +#include <linux/acpi_iort.h>
>>> #include <linux/device.h>
>>> -#include <linux/idr.h>
>>> #include <linux/irq.h>
>>> #include <linux/irqdomain.h>
>>> #include <linux/msi.h>
>>> @@ -416,3 +416,16 @@ int platform_msi_domain_alloc(struct irq_domain *domain, unsigned int virq,
>>>
>>> return err;
>>> }
>>> +
>>> +int acpi_configure_msi_domain(struct device *dev)
>>> +{
>>> + struct irq_domain *d = NULL;
>>> +
>>> + d = iort_get_device_domain(dev, 0);
>>
>> This looks completely wrong. Why RID 0? As far as I can see, 0 is not a
>> special value, and could be something else.
>
> You are right. I tried to reuse the API of get irqdomain in IORT for
> PCI devices, but for platform device, we don't have req id in named
> component, so I just pass 0 here, I think I need to prepare another
> API for platform devices.
>
>>
>>> + if (d) {
>>> + dev_set_msi_domain(dev, d);
>>> + return 0;
>>> + }
>>> +
>>> + return -EINVAL;
>>> +}
>>
>> I really hate this, as the platform MSI code is intentionally free of
>> any firmware reference. This should live in the ACPI code.
>
> Will do, I think locate it in iort.c is better.
>
>>
>>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>>> index 6482d47..ea01a37 100644
>>> --- a/drivers/base/platform.c
>>> +++ b/drivers/base/platform.c
>>> @@ -24,6 +24,7 @@
>>> #include <linux/pm_domain.h>
>>> #include <linux/idr.h>
>>> #include <linux/acpi.h>
>>> +#include <linux/msi.h>
>>> #include <linux/clk/clk-conf.h>
>>> #include <linux/limits.h>
>>> #include <linux/property.h>
>>> @@ -500,6 +501,7 @@ struct platform_device *platform_device_register_full(
>>> pdev->dev.parent = pdevinfo->parent;
>>> pdev->dev.fwnode = pdevinfo->fwnode;
>>>
>>> + acpi_configure_msi_domain(&pdev->dev);
>>
>> It feels odd to put this in the generic code, while you could perfectly
>> put the call into acpi_platform.c and keep the firmware stuff away from
>> the generic code.
>
> My feeling is the same, I'm still trying to find a new way to do it,
> but I can't simply put that in acpi_platform.c, because
>
> acpi_create_platform_device()
> platform_device_register_full()
> platform_device_alloc() --> dev is alloced
> ...
> dev.fwnode is set
> (I get the msi domain by the fwnode in acpi_configure_msi_domain)
> ...
> platform_device_add() --> which the device is probed.
>
> For devices like irqchip which needs the dev->msi_domain to be
> set before it's really probed, because it needs the msi domain
> to be the parent domain.
>
> If I call the function in acpi_create_platform_device() before
> platform_device_register_full(), we just can't set dev's msi
> domain, but if call it after platform_device_register_full(),
> the irqchip like mbigen will not get its parent domain...
>
> DT is using another API for platform device probe, so has no
> problems like I said above, any suggestions to do it right in
> ACPI?
How about having something that's completely generic and solves
the problem once and for all? Something like this:
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 6482d47..6f0f90b 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -533,6 +533,9 @@ struct platform_device *platform_device_register_full(
goto err;
}
+ if (pdevinfo->pre_add_cb)
+ pdevinfo->pre_add_cb(&pdev->dev);
+
ret = platform_device_add(pdev);
if (ret) {
err:
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 98c2a7c..44ea133 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -74,6 +74,7 @@ struct platform_device_info {
u64 dma_mask;
struct property_entry *properties;
+ void (*pre_add_cb)(struct device *);
};
extern struct platform_device *platform_device_register_full(
const struct platform_device_info *pdevinfo);
Plug pre_add_cb with your ACPI callback where you can do all the
processing you want before the device is actually added.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* [PATCH v3 2/3] ASoC: rename "SUN4I_CODEC_SYS_VERI" to "SUN7I_CODEC_AC_DAC_CAL"; rename "SUN4I_CODEC_AC_MIC_PHONE_CAL" to "SUN7I_CODEC_AC_MIC_PHONE_CAL".
From: Chen-Yu Tsai @ 2016-09-15 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-3-dannym@scratchpost.org>
On Thu, Sep 15, 2016 at 10:39 PM, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
> This patch renames some sun7i-only registers to reflect that fact.
The subject line is way longer than it should be. Perhaps you could use
the above message as the description part of the subject?
ChenYu
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index c2c0583..3b53b78 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -96,8 +96,8 @@
> /* Other various ADC registers */
> #define SUN4I_CODEC_DAC_TXCNT (0x30)
> #define SUN4I_CODEC_ADC_RXCNT (0x34)
> -#define SUN4I_CODEC_AC_SYS_VERI (0x38)
> -#define SUN4I_CODEC_AC_MIC_PHONE_CAL (0x3c)
> +#define SUN7I_CODEC_AC_DAC_CAL (0x38)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
>
> struct sun4i_codec {
> struct device *dev;
> @@ -682,7 +682,7 @@ static const struct regmap_config sun4i_codec_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> - .max_register = SUN4I_CODEC_AC_MIC_PHONE_CAL,
> + .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
> };
>
> static const struct of_device_id sun4i_codec_of_match[] = {
^ permalink raw reply
* [PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate
From: Chen-Yu Tsai @ 2016-09-15 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915151402.15992-1-wens@csie.org>
With display pixel clocks we want to have the closest possible clock
rate, to minimize timing and refresh rate skews. Whether the actual
clock rate is higher or lower than the requested rate is less important.
Also check candidates against the requested rate, rather than the
ideal parent rate, the varying dividers also influence the difference
between the requested rate and the rounded rate.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
index 3eb99784f371..d401156490f3 100644
--- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
+++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
@@ -90,7 +90,8 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
goto out;
}
- if ((rounded < ideal) && (rounded > best_parent)) {
+ if (abs(rate - rounded / i) <
+ abs(rate - best_parent / best_div)) {
best_parent = rounded;
best_div = i;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] drm/sun4i: dotclock: Allow divider = 127
From: Chen-Yu Tsai @ 2016-09-15 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915151402.15992-1-wens@csie.org>
The dot clock divider is 7 bits wide, and the divider range is 1 ~ 127,
or 6 ~ 127 if phase offsets are used. The 0 register value also
represents a divider of 1 or bypass.
Make the end condition of the for loop inclusive of 127 in the
round_rate callback.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/gpu/drm/sun4i/sun4i_dotclock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
index 1b6c2253192e..3eb99784f371 100644
--- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c
+++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c
@@ -77,7 +77,7 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
u8 best_div = 1;
int i;
- for (i = 6; i < 127; i++) {
+ for (i = 6; i <= 127; i++) {
unsigned long ideal = rate * i;
unsigned long rounded;
--
2.9.3
^ 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