* Re: [PATCH 4/4] KVM: PPC: Bookehv: Get vcpu's last instruction for emulation
From: Scott Wood @ 2014-03-26 21:17 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1392913821-4520-4-git-send-email-mihai.caraman@freescale.com>
On Thu, 2014-02-20 at 18:30 +0200, Mihai Caraman wrote:
> Load external pid (lwepx) instruction faults (when called from
> KVM with guest context) needs to be handled by KVM. This implies
> additional code in DO_KVM macro to identify the source of the
> exception (which oiginate from KVM host rather than the guest).
> The hook requires to check the Exception Syndrome Register
> ESR[EPID] and External PID Load Context Register EPLC[EGS] for
> some exceptions (DTLB_MISS, DSI and LRAT). Doing this on Data TLB
> miss exception is obvious intrusive for the host.
>
> Get rid of lwepx and acquire last instuction in kvmppc_get_last_inst()
> by searching for the physical address and kmap it. This fixes an
> infinite loop caused by lwepx's data TLB miss handled in the host
> and the TODO for TLB eviction and execute-but-not-read entries.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/bookehv_interrupts.S | 37 +++----------
> arch/powerpc/kvm/e500_mmu_host.c | 93 +++++++++++++++++++++++++++++++++
> 2 files changed, 102 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S
> index 20c7a54..c50490c 100644
> --- a/arch/powerpc/kvm/bookehv_interrupts.S
> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
> @@ -119,38 +119,14 @@
> 1:
>
> .if \flags & NEED_EMU
> - /*
> - * This assumes you have external PID support.
> - * To support a bookehv CPU without external PID, you'll
> - * need to look up the TLB entry and create a temporary mapping.
> - *
> - * FIXME: we don't currently handle if the lwepx faults. PR-mode
> - * booke doesn't handle it either. Since Linux doesn't use
> - * broadcast tlbivax anymore, the only way this should happen is
> - * if the guest maps its memory execute-but-not-read, or if we
> - * somehow take a TLB miss in the middle of this entry code and
> - * evict the relevant entry. On e500mc, all kernel lowmem is
> - * bolted into TLB1 large page mappings, and we don't use
> - * broadcast invalidates, so we should not take a TLB miss here.
> - *
> - * Later we'll need to deal with faults here. Disallowing guest
> - * mappings that are execute-but-not-read could be an option on
> - * e500mc, but not on chips with an LRAT if it is used.
> - */
> -
> - mfspr r3, SPRN_EPLC /* will already have correct ELPID and EGS */
> PPC_STL r15, VCPU_GPR(R15)(r4)
> PPC_STL r16, VCPU_GPR(R16)(r4)
> PPC_STL r17, VCPU_GPR(R17)(r4)
> PPC_STL r18, VCPU_GPR(R18)(r4)
> PPC_STL r19, VCPU_GPR(R19)(r4)
> - mr r8, r3
> PPC_STL r20, VCPU_GPR(R20)(r4)
> - rlwimi r8, r6, EPC_EAS_SHIFT - MSR_IR_LG, EPC_EAS
> PPC_STL r21, VCPU_GPR(R21)(r4)
> - rlwimi r8, r6, EPC_EPR_SHIFT - MSR_PR_LG, EPC_EPR
> PPC_STL r22, VCPU_GPR(R22)(r4)
> - rlwimi r8, r10, EPC_EPID_SHIFT, EPC_EPID
> PPC_STL r23, VCPU_GPR(R23)(r4)
> PPC_STL r24, VCPU_GPR(R24)(r4)
> PPC_STL r25, VCPU_GPR(R25)(r4)
> @@ -160,10 +136,15 @@
> PPC_STL r29, VCPU_GPR(R29)(r4)
> PPC_STL r30, VCPU_GPR(R30)(r4)
> PPC_STL r31, VCPU_GPR(R31)(r4)
> - mtspr SPRN_EPLC, r8
> - isync
> - lwepx r9, 0, r5
> - mtspr SPRN_EPLC, r3
> +
> + /*
> + * We don't use external PID support. lwepx faults would need to be
> + * handled by KVM and this implies aditional code in DO_KVM (for
> + * DTB_MISS, DSI and LRAT) to check ESR[EPID] and EPLC[EGS] which
> + * is too intrusive for the host. Get last instuction in
> + * kvmppc_get_last_inst().
> + */
> + li r9, KVM_INST_FETCH_FAILED
> stw r9, VCPU_LAST_INST(r4)
> .endif
>
> diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
> index 6025cb7..1b4cb41 100644
> --- a/arch/powerpc/kvm/e500_mmu_host.c
> +++ b/arch/powerpc/kvm/e500_mmu_host.c
> @@ -598,9 +598,102 @@ void kvmppc_mmu_map(struct kvm_vcpu *vcpu, u64 eaddr, gpa_t gpaddr,
> }
> }
>
> +#ifdef CONFIG_KVM_BOOKE_HV
> +int kvmppc_ld_inst(struct kvm_vcpu *vcpu, u32 *instr)
It'd be interesting to see what the performance impact of doing this on
non-HV would be -- it would eliminate divergent code, eliminate the
MSR_DS hack, and make exec-only mappings work.
> +{
> + gva_t geaddr;
> + hpa_t addr;
> + hfn_t pfn;
> + hva_t eaddr;
> + u32 mas0, mas1, mas2, mas3;
> + u64 mas7_mas3;
> + struct page *page;
> + unsigned int addr_space, psize_shift;
> + bool pr;
> + unsigned long flags;
> +
> + /* Search TLB for guest pc to get the real address */
> + geaddr = kvmppc_get_pc(vcpu);
> + addr_space = (vcpu->arch.shared->msr & MSR_IS) >> MSR_IR_LG;
> +
> + local_irq_save(flags);
> + mtspr(SPRN_MAS6, (vcpu->arch.pid << MAS6_SPID_SHIFT) | addr_space);
> + mtspr(SPRN_MAS5, MAS5_SGS | vcpu->kvm->arch.lpid);
> + isync();
> + asm volatile("tlbsx 0, %[geaddr]\n" : : [geaddr] "r" (geaddr));
We can probably get away without that isync, despite what the manual
says. We've been doing it in other contexts on e500 since forever, and
tlbsx has presync serialization which means it already waits for all
previous instructions to complete before beginning execution.
> + mtspr(SPRN_MAS5, 0);
> + mtspr(SPRN_MAS8, 0);
> + mas0 = mfspr(SPRN_MAS0);
> + mas1 = mfspr(SPRN_MAS1);
> + mas2 = mfspr(SPRN_MAS2);
> + mas3 = mfspr(SPRN_MAS3);
> + mas7_mas3 = (((u64) mfspr(SPRN_MAS7)) << 32) | mfspr(SPRN_MAS3);
Why read mas3 twice?
> + local_irq_restore(flags);
> +
> + /*
> + * If the TLB entry for guest pc was evicted, return to the guest.
> + * There are high chances to find a valid TLB entry next time.
> + */
> + if (!(mas1 & MAS1_VALID))
> + return EMULATE_AGAIN;
> +
> + /*
> + * Another thread may rewrite the TLB entry in parallel, don't
> + * execute from the address if the execute permission is not set
> + */
> + pr = vcpu->arch.shared->msr & MSR_PR;
> + if ((pr && (!(mas3 & MAS3_UX))) || ((!pr) && (!(mas3 & MAS3_SX)))) {
> + kvmppc_core_queue_inst_storage(vcpu, 0);
> + return EMULATE_AGAIN;
> + }
s/(!foo)/!foo/g
> + /*
> + * We will map the real address through a cacheable page, so we will
> + * not support cache-inhibited guest pages. Fortunately emulated
> + * instructions should not live there.
> + */
> + if (mas2 & MAS2_I) {
> + printk(KERN_CRIT "Instuction emulation from cache-inhibited "
> + "guest pages is not supported\n");
> + return EMULATE_FAIL;
> + }
This message needs to be ratelimited, and use pr_err() (or maybe even
pr_debug()).
> + /* Get page size */
> + if (MAS0_GET_TLBSEL(mas0) == 0)
> + psize_shift = PAGE_SHIFT;
> + else
> + psize_shift = MAS1_GET_TSIZE(mas1) + 10;
TSIZE should be correct when reading from TLB0, even if it was incorrect
(and ignored) when writing.
> + /* Map a page and get guest's instruction */
> + addr = (mas7_mas3 & (~0ULL << psize_shift)) |
> + (geaddr & ((1ULL << psize_shift) - 1ULL));
> + pfn = addr >> PAGE_SHIFT;
> +
> + if (unlikely(!pfn_valid(pfn))) {
> + printk(KERN_CRIT "Invalid frame number\n");
> + return EMULATE_FAIL;
> + }
> +
> + /* Guard us against emulation from devices area */
> + if (unlikely(!page_is_ram(pfn))) {
> + printk(KERN_CRIT "Instruction emulation from non-RAM host "
> + "pages is not supported\n");
> + return EMULATE_FAIL;
> + }
Same comment as the cache-inhibited message, and you can probably have
one message for both pfn_valid and page_is_ram (is one of those a subset
of the other?).
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Mark Brown @ 2014-03-27 1:14 UTC (permalink / raw)
To: David Laight
Cc: alsa-devel@alsa-project.org, Li.Xiubo@freescale.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
'Nicolin Chen'
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D0F6E958E@AcuExch.aculab.com>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
On Wed, Mar 26, 2014 at 11:59:53AM +0000, David Laight wrote:
> From: Nicolin Chen
> > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
> Assuming these are 'write to clear' bits, you might want
> to make the write (above) and all the traces (below)
> conditional on the value being non-zero.
The trace is already conditional? I'd also expect to see the driver
only acknowledging sources it knows about and only reporting that the
interrupt was handled if it saw one of them - right now all interrupts
are unconditionally acknowleged.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Li.Xiubo @ 2014-03-27 2:13 UTC (permalink / raw)
To: guangyu.chen@freescale.com, broonie@kernel.org
Cc: alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1395834517-16426-1-git-send-email-Guangyu.Chen@freescale.com>
> + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
> +
> + if (xcsr & FSL_SAI_CSR_WSF)
> + dev_dbg(dev, "isr: Start of Tx word detected\n");
> +
> + if (xcsr & FSL_SAI_CSR_SEF)
> + dev_dbg(dev, "isr: Tx Frame sync error detected\n");
> +
> + if (xcsr & FSL_SAI_CSR_FEF)
> + dev_dbg(dev, "isr: Transmit underrun detected\n");
> +
Actually, the above three isrs should to write a logic 1 to this field
to clear this flag.
> + if (xcsr & FSL_SAI_CSR_FWF)
> + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> +
> + if (xcsr & FSL_SAI_CSR_FRF)
> + dev_dbg(dev, "isr: Transmit FIFO watermark has been reached\n");
> +
While are these ones really needed to clear manually ?
Thanks,
--
Best Regards,
Xiubo
^ permalink raw reply
* Re: [alsa-devel] [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Nicolin Chen @ 2014-03-27 2:29 UTC (permalink / raw)
To: Mark Brown
Cc: Li.Xiubo@freescale.com, alsa-devel@alsa-project.org, David Laight,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140327011424.GB30768@sirena.org.uk>
On Thu, Mar 27, 2014 at 01:14:24AM +0000, Mark Brown wrote:
> On Wed, Mar 26, 2014 at 11:59:53AM +0000, David Laight wrote:
> > From: Nicolin Chen
>
> > > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
>
> > Assuming these are 'write to clear' bits, you might want
> > to make the write (above) and all the traces (below)
> > conditional on the value being non-zero.
>
> The trace is already conditional? I'd also expect to see the driver
> only acknowledging sources it knows about and only reporting that the
> interrupt was handled if it saw one of them - right now all interrupts
> are unconditionally acknowleged.
Will revise it based on the comments from both of you.
Thank you.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Nicolin Chen @ 2014-03-27 2:36 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <11a8271c31044515bd2657a93aefdaec@BY2PR03MB505.namprd03.prod.outlook.com>
On Thu, Mar 27, 2014 at 10:13:48AM +0800, Xiubo Li-B47053 wrote:
> > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
> > +
> > + if (xcsr & FSL_SAI_CSR_WSF)
> > + dev_dbg(dev, "isr: Start of Tx word detected\n");
> > +
> > + if (xcsr & FSL_SAI_CSR_SEF)
> > + dev_dbg(dev, "isr: Tx Frame sync error detected\n");
> > +
> > + if (xcsr & FSL_SAI_CSR_FEF)
> > + dev_dbg(dev, "isr: Transmit underrun detected\n");
> > +
>
> Actually, the above three isrs should to write a logic 1 to this field
> to clear this flag.
>
>
> > + if (xcsr & FSL_SAI_CSR_FWF)
> > + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> > +
> > + if (xcsr & FSL_SAI_CSR_FRF)
> > + dev_dbg(dev, "isr: Transmit FIFO watermark has been reached\n");
> > +
>
> While are these ones really needed to clear manually ?
The reference manual doesn't mention about the requirement. So SAI should do
the self-clearance.
^ permalink raw reply
* RE: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Li.Xiubo @ 2014-03-27 2:53 UTC (permalink / raw)
To: guangyu.chen@freescale.com
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140327023617.GB16197@MrMyself>
> On Thu, Mar 27, 2014 at 10:13:48AM +0800, Xiubo Li-B47053 wrote:
> > > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
> > > +
> > > + if (xcsr & FSL_SAI_CSR_WSF)
> > > + dev_dbg(dev, "isr: Start of Tx word detected\n");
> > > +
> > > + if (xcsr & FSL_SAI_CSR_SEF)
> > > + dev_dbg(dev, "isr: Tx Frame sync error detected\n");
> > > +
> > > + if (xcsr & FSL_SAI_CSR_FEF)
> > > + dev_dbg(dev, "isr: Transmit underrun detected\n");
> > > +
> >
> > Actually, the above three isrs should to write a logic 1 to this field
> > to clear this flag.
> >
> >
> > > + if (xcsr & FSL_SAI_CSR_FWF)
> > > + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> > > +
> > > + if (xcsr & FSL_SAI_CSR_FRF)
> > > + dev_dbg(dev, "isr: Transmit FIFO watermark has been reached\n");
> > > +
> >
> > While are these ones really needed to clear manually ?
>=20
> The reference manual doesn't mention about the requirement. So SAI should=
do
> the self-clearance.
Yes, I do think we should let it do the self-clearance, and shouldn't inter=
fere
of them...
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Nicolin Chen @ 2014-03-27 2:56 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1e2d210764724c7e834c5307b54c37ab@BY2PR03MB505.namprd03.prod.outlook.com>
On Thu, Mar 27, 2014 at 10:53:50AM +0800, Xiubo Li-B47053 wrote:
> > On Thu, Mar 27, 2014 at 10:13:48AM +0800, Xiubo Li-B47053 wrote:
> > > > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > > > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
> > > > +
> > > > + if (xcsr & FSL_SAI_CSR_WSF)
> > > > + dev_dbg(dev, "isr: Start of Tx word detected\n");
> > > > +
> > > > + if (xcsr & FSL_SAI_CSR_SEF)
> > > > + dev_dbg(dev, "isr: Tx Frame sync error detected\n");
> > > > +
> > > > + if (xcsr & FSL_SAI_CSR_FEF)
> > > > + dev_dbg(dev, "isr: Transmit underrun detected\n");
> > > > +
> > >
> > > Actually, the above three isrs should to write a logic 1 to this field
> > > to clear this flag.
> > >
> > >
> > > > + if (xcsr & FSL_SAI_CSR_FWF)
> > > > + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> > > > +
> > > > + if (xcsr & FSL_SAI_CSR_FRF)
> > > > + dev_dbg(dev, "isr: Transmit FIFO watermark has been reached\n");
> > > > +
> > >
> > > While are these ones really needed to clear manually ?
> >
> > The reference manual doesn't mention about the requirement. So SAI should do
> > the self-clearance.
>
> Yes, I do think we should let it do the self-clearance, and shouldn't interfere
> of them...
SAI is supposed to ignore the interference, isn't it?
^ permalink raw reply
* Re: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Timur Tabi @ 2014-03-27 3:35 UTC (permalink / raw)
To: Jason.Jin@freescale.com
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <f6883c3f759a4544936acec5dc7e542b@BLUPR03MB373.namprd03.prod.outlook.com>
Jason.Jin@freescale.com wrote:
>>>>> However, the DIU is already initialized in u-boot and we can
>>>>> rely on the settings in u-boot for corenet platform,
>>>
>>> I don't like that at all.
> [Jason Jin-R64188] What's the potential issue of this? Most of the
> IPs need the platform initialization in u-boot. For example, the
> hwconfig in u-boot used for board specific settings for most
> platform.
The potential problem is that it's not stable. Power management breaks
your code.
I won't NACK your patch, but it feels like a band-aid rather than a real
solution.
^ permalink raw reply
* RE: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Jason.Jin @ 2014-03-27 3:38 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <53339C96.3070406@tabi.org>
> Jason.Jin@freescale.com wrote:
> >>>>> However, the DIU is already initialized in u-boot and we can rely
> >>>>> on the settings in u-boot for corenet platform,
> >>>
> >>> I don't like that at all.
> > [Jason Jin-R64188] What's the potential issue of this? Most of the IPs
> > need the platform initialization in u-boot. For example, the hwconfig
> > in u-boot used for board specific settings for most platform.
>=20
> The potential problem is that it's not stable. Power management breaks
> your code.
>=20
> I won't NACK your patch, but it feels like a band-aid rather than a real
> solution.
>=20
[Jason Jin-R64188] Thanks. The power management will break the pixel clock =
only. We can try to fix it separately. I'll try to explain it in that mail.
^ permalink raw reply
* RE: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Li.Xiubo @ 2014-03-27 3:41 UTC (permalink / raw)
To: guangyu.chen@freescale.com
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140327025647.GC16197@MrMyself>
> Subject: Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
>=20
> On Thu, Mar 27, 2014 at 10:53:50AM +0800, Xiubo Li-B47053 wrote:
> > > On Thu, Mar 27, 2014 at 10:13:48AM +0800, Xiubo Li-B47053 wrote:
> > > > > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > > > > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
> > > > > +
> > > > > + if (xcsr & FSL_SAI_CSR_WSF)
> > > > > + dev_dbg(dev, "isr: Start of Tx word detected\n");
> > > > > +
> > > > > + if (xcsr & FSL_SAI_CSR_SEF)
> > > > > + dev_dbg(dev, "isr: Tx Frame sync error detected\n");
> > > > > +
> > > > > + if (xcsr & FSL_SAI_CSR_FEF)
> > > > > + dev_dbg(dev, "isr: Transmit underrun detected\n");
> > > > > +
> > > >
> > > > Actually, the above three isrs should to write a logic 1 to this fi=
eld
> > > > to clear this flag.
> > > >
> > > >
> > > > > + if (xcsr & FSL_SAI_CSR_FWF)
> > > > > + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> > > > > +
> > > > > + if (xcsr & FSL_SAI_CSR_FRF)
> > > > > + dev_dbg(dev, "isr: Transmit FIFO watermark has been
> reached\n");
> > > > > +
> > > >
> > > > While are these ones really needed to clear manually ?
> > >
> > > The reference manual doesn't mention about the requirement. So SAI sh=
ould
> do
> > > the self-clearance.
> >
> > Yes, I do think we should let it do the self-clearance, and shouldn't
> interfere
> > of them...
>=20
> SAI is supposed to ignore the interference, isn't it?
>=20
Maybe, but I'm not very sure.
And these bits are all writable and readable.
^ permalink raw reply
* RE: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason.Jin @ 2014-03-27 3:42 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <53332168.5050805@tabi.org>
>=20
> On 03/26/2014 12:41 PM, Jason Jin wrote:
> > + if (!diu_ops.set_pixel_clock) {
> > + data->saved_pixel_clock =3D 0;
> > + if (of_address_to_resource(ofdev->dev.of_node, 1, &res))
> > + pr_err(KERN_ERR "No pixel clock set func and no pixel
> node!\n");
> > + else {
> > + data->pixelclk_ptr =3D
> > + devm_ioremap(&ofdev->dev, res.start,
> resource_size(&res));
> > + if (!data->pixelclk_ptr) {
> > + pr_err(KERN_ERR "fslfb: could not map pixelclk
> register!\n");
> > + ret =3D -ENOMEM;
> > + } else
> > + data->saved_pixel_clock =3D in_be32(data-
> >pixelclk_ptr);
> > + }
> > + }
>=20
> This seems very hackish. What node does ofdev point to? I wonder if
> this code should be in the platform file instead.
>=20
[Jason Jin-R64188] It's not hackish, we can provide the pixel clock registe=
r in the DIU node, I did not provide the dts update as this is only tested =
on T1040 platform. For other platforms such as p1022 and 8610, we still can=
use the pixel clock setting function in the platform.=20
The dts node update for T1040 is:
display:display@180000 {
compatible =3D "fsl,t1040-diu", "fsl,diu";
- reg =3D <0x180000 1000>;
+ reg =3D <0x180000 1000 0xfc028 4>;
interrupts =3D <74 2 0 0>;
};
If saving the pixel clock register likes a hackish. We can provide more inf=
ormation in the node to move the pixel clock settings to the driver. It see=
ms that we only need to provide another parameter(the ratio) for pixel cloc=
k setting.
> Also, use dev_info() instead of pr_err, and never use exclamation marks
> in driver messages.
Ok, Thanks.
^ permalink raw reply
* RE: [PATCH 1/2] video/fsl: make the diu driver work without platform hooks
From: Jason.Jin @ 2014-03-27 3:30 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <533320A0.8010507@tabi.org>
> On 03/26/2014 12:41 PM, Jason Jin wrote:
> > This board sepecific initialization mechanism is not feasible i for
> > corenet platform as the corenet platform file is a abstraction of
> > serveral platforms.
>=20
> You can't make it 100% abstract. The DIU driver requires some sort of
> board support. I think you can make a generic platform file for the DIU.
>=20
[Jason Jin-R64188] Provide the generic diu platform file is reasonable, but=
it is will be just the board specific initialization file collection, if w=
e really need to reinitialize something in kernel.=20
> > However, the DIU is already initialized in u-boot and we can rely on
> > the settings in u-boot for corenet platform,
>=20
> I don't like that at all.
[Jason Jin-R64188] What's the potential issue of this? Most of the IPs need=
the platform initialization in u-boot. For example, the hwconfig in u-boot=
used for board specific settings for most platform.
The diu_ops structure is still open for any board specific initialization i=
f the platform needed. We at least can let the platform to select to use th=
e diu_ops or not. This is the purse for this patch.
>=20
> > the only
> > issue is that when DIU wake up from the deepsleep, some of the board
> > specific initialization will lost, such as the pixel clock setting.
>=20
> That is a BIG issue. This is why we have a platform file -- to handle
> the platform issues.
[Jason Jin-R64188] Yes, this is an issue, Actually, this is a SOC level iss=
ue, We can try to fix it in the driver by saving the pixel clock in suspend=
function and restored it in resume function.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Timur Tabi @ 2014-03-27 3:46 UTC (permalink / raw)
To: Jason.Jin@freescale.com
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <e3e45edb388c482eb53474e18575f227@BLUPR03MB373.namprd03.prod.outlook.com>
Jason.Jin@freescale.com wrote:
> [Jason Jin-R64188] It's not hackish, we can provide the pixel clock register in the DIU node, I did not provide the dts update as this is only tested on T1040 platform. For other platforms such as p1022 and 8610, we still can use the pixel clock setting function in the platform.
>
> The dts node update for T1040 is:
> display:display@180000 {
> compatible = "fsl,t1040-diu", "fsl,diu";
> - reg = <0x180000 1000>;
> + reg = <0x180000 1000 0xfc028 4>;
> interrupts = <74 2 0 0>;
> };
This is hackish because you're specifying a single register that you
want to preserve in the DTS file, instead of a platform function which
is where it's supposed to be.
I will think about this some more. I think you are trying too hard to
avoid a platform file, which is why some of this code is hackish to me.
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Nicolin Chen @ 2014-03-27 3:31 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <12f887b3889a41849026965f0cf7db1f@BY2PR03MB505.namprd03.prod.outlook.com>
On Thu, Mar 27, 2014 at 11:41:02AM +0800, Xiubo Li-B47053 wrote:
>
> > Subject: Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
> >
> > On Thu, Mar 27, 2014 at 10:53:50AM +0800, Xiubo Li-B47053 wrote:
> > > > On Thu, Mar 27, 2014 at 10:13:48AM +0800, Xiubo Li-B47053 wrote:
> > > > > > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > > > > > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
> > > > > > +
> > > > > > + if (xcsr & FSL_SAI_CSR_WSF)
> > > > > > + dev_dbg(dev, "isr: Start of Tx word detected\n");
> > > > > > +
> > > > > > + if (xcsr & FSL_SAI_CSR_SEF)
> > > > > > + dev_dbg(dev, "isr: Tx Frame sync error detected\n");
> > > > > > +
> > > > > > + if (xcsr & FSL_SAI_CSR_FEF)
> > > > > > + dev_dbg(dev, "isr: Transmit underrun detected\n");
> > > > > > +
> > > > >
> > > > > Actually, the above three isrs should to write a logic 1 to this field
> > > > > to clear this flag.
> > > > >
> > > > >
> > > > > > + if (xcsr & FSL_SAI_CSR_FWF)
> > > > > > + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> > > > > > +
> > > > > > + if (xcsr & FSL_SAI_CSR_FRF)
> > > > > > + dev_dbg(dev, "isr: Transmit FIFO watermark has been
> > reached\n");
> > > > > > +
> > > > >
> > > > > While are these ones really needed to clear manually ?
> > > >
> > > > The reference manual doesn't mention about the requirement. So SAI should
> > do
> > > > the self-clearance.
> > >
> > > Yes, I do think we should let it do the self-clearance, and shouldn't
> > interfere
> > > of them...
> >
> > SAI is supposed to ignore the interference, isn't it?
> >
>
> Maybe, but I'm not very sure.
> And these bits are all writable and readable.
Double-confirmed? Because FWF and FRF should be read-only bits.
^ permalink raw reply
* Re: [PATCH v4] powernv, cpufreq: cpufreq driver for powernv platform
From: Anton Blanchard @ 2014-03-27 3:56 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Linux PM list, Viresh Kumar, linuxppc-dev, srivatsa.bhat
In-Reply-To: <1395852947-22290-2-git-send-email-ego@linux.vnet.ibm.com>
Hi Gautham,
> Backend driver to dynamically set voltage and frequency on
> IBM POWER non-virtualized platforms. Power management SPRs
> are used to set the required PState.
I tested this version on ppc64le, it still looks good. I'm already
a Signed-off-by on the patch, but feel free to add:
Tested-by: Anton Blanchard <anton@samba.org>
Anton
^ permalink raw reply
* RE: [PATCH 2/2] video/fsl: Fix the sleep function for FSL DIU module
From: Jason.Jin @ 2014-03-27 3:57 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, linux-fbdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Dongsheng.Wang@freescale.com
In-Reply-To: <53339F03.7010004@tabi.org>
> Jason.Jin@freescale.com wrote:
> > [Jason Jin-R64188] It's not hackish, we can provide the pixel clock
> register in the DIU node, I did not provide the dts update as this is
> only tested on T1040 platform. For other platforms such as p1022 and 8610=
,
> we still can use the pixel clock setting function in the platform.
> >
> > The dts node update for T1040 is:
> > display:display@180000 {
> > compatible =3D "fsl,t1040-diu", "fsl,diu";
> > - reg =3D <0x180000 1000>;
> > + reg =3D <0x180000 1000 0xfc028 4>;
> > interrupts =3D <74 2 0 0>;
> > };
>=20
> This is hackish because you're specifying a single register that you want
> to preserve in the DTS file, instead of a platform function which is
> where it's supposed to be.
>=20
[Jason Jin-R64188] The pixel clock register is actually part of the DIU reg=
isters although it is not implemented in the diu module. Actually we can us=
e it to set pixel clock in the driver not just saving it in suspend. We can=
provide the patch for discussion.=20
> I will think about this some more. I think you are trying too hard to
> avoid a platform file, which is why some of this code is hackish to me.
[Jason Jin-R64188] Thanks. Could you please share you thinking for how to s=
etup the platform file then?
^ permalink raw reply
* RE: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Li.Xiubo @ 2014-03-27 4:06 UTC (permalink / raw)
To: guangyu.chen@freescale.com
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140327033117.GD16197@MrMyself>
> > > > > > > + if (xcsr & FSL_SAI_CSR_FWF)
> > > > > > > + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> > > > > > > +
> > > > > > > + if (xcsr & FSL_SAI_CSR_FRF)
> > > > > > > + dev_dbg(dev, "isr: Transmit FIFO watermark has been
> > > reached\n");
> > > > > > > +
> > > > > >
> > > > > > While are these ones really needed to clear manually ?
> > > > >
> > > > > The reference manual doesn't mention about the requirement. So SA=
I
> should
> > > do
> > > > > the self-clearance.
> > > >
> > > > Yes, I do think we should let it do the self-clearance, and shouldn=
't
> > > interfere
> > > > of them...
> > >
> > > SAI is supposed to ignore the interference, isn't it?
> > >
> >
> > Maybe, but I'm not very sure.
> > And these bits are all writable and readable.
>=20
> Double-confirmed? Because FWF and FRF should be read-only bits.
>=20
So let's just ignore the clearance of these bits in isr().
+++++
SAI Transmit Control Register (I2S1_TCSR) : 32 : R/W : 0000_0000h
-----
I have checked in the Vybrid and LS1 SoC datasheets, and they are all the
Same as above, and nothing else.
Have I missed ?
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Nicolin Chen @ 2014-03-27 3:57 UTC (permalink / raw)
To: Xiubo Li-B47053
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <62630844c7434df6937ca25d3f47b656@BY2PR03MB505.namprd03.prod.outlook.com>
On Thu, Mar 27, 2014 at 12:06:53PM +0800, Xiubo Li-B47053 wrote:
> > > > > > > > + if (xcsr & FSL_SAI_CSR_FWF)
> > > > > > > > + dev_dbg(dev, "isr: Enabled transmit FIFO is empty\n");
> > > > > > > > +
> > > > > > > > + if (xcsr & FSL_SAI_CSR_FRF)
> > > > > > > > + dev_dbg(dev, "isr: Transmit FIFO watermark has been
> > > > reached\n");
> > > > > > > > +
> > > > > > >
> > > > > > > While are these ones really needed to clear manually ?
> > > > > >
> > > > > > The reference manual doesn't mention about the requirement. So SAI
> > should
> > > > do
> > > > > > the self-clearance.
> > > > >
> > > > > Yes, I do think we should let it do the self-clearance, and shouldn't
> > > > interfere
> > > > > of them...
> > > >
> > > > SAI is supposed to ignore the interference, isn't it?
> > > >
> > >
> > > Maybe, but I'm not very sure.
> > > And these bits are all writable and readable.
> >
> > Double-confirmed? Because FWF and FRF should be read-only bits.
> >
>
> So let's just ignore the clearance of these bits in isr().
>
> +++++
> SAI Transmit Control Register (I2S1_TCSR) : 32 : R/W : 0000_0000h
I'm talking about FWF and FRF bits, not TCSR as a register.
> -----
>
> I have checked in the Vybrid and LS1 SoC datasheets, and they are all the
> Same as above, and nothing else.
>
> Have I missed ?
What i.MX IC team told me is SAI ignores what we do to FWF and FRF, so you
don't need to worry about it at all unless Vybrid makes them writable, in
which case we may also need to clear these bits and confirm with Vybrid IC
team if they're also W1C.
^ permalink raw reply
* RE: [PATCH] ASoC: fsl_sai: Add isr to deal with error flag
From: Li.Xiubo @ 2014-03-27 4:18 UTC (permalink / raw)
To: guangyu.chen@freescale.com
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20140327035726.GA16359@MrMyself>
> > So let's just ignore the clearance of these bits in isr().
> >
> > +++++
> > SAI Transmit Control Register (I2S1_TCSR) : 32 : R/W : 0000_0000h
>=20
> I'm talking about FWF and FRF bits, not TCSR as a register.
>=20
> > -----
> >
> > I have checked in the Vybrid and LS1 SoC datasheets, and they are all t=
he
> > Same as above, and nothing else.
> >
> > Have I missed ?
>=20
> What i.MX IC team told me is SAI ignores what we do to FWF and FRF, so yo=
u
> don't need to worry about it at all unless Vybrid makes them writable, in
> which case we may also need to clear these bits and confirm with Vybrid I=
C
> team if they're also W1C.
>=20
Well, if so, that's fine.
Thanks,
^ permalink raw reply
* [PATCH 1/4] powerpc/powernv: Use uint64_t instead of size_t in OPAL APIs
From: Anton Blanchard @ 2014-03-27 5:18 UTC (permalink / raw)
To: stewart, benh, paulus; +Cc: linuxppc-dev
Using size_t in our APIs is asking for trouble, especially
when some OPAL calls use size_t pointers.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: b/arch/powerpc/include/asm/opal.h
===================================================================
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -850,8 +850,8 @@ int64_t opal_lpc_write(uint32_t chip_id,
int64_t opal_lpc_read(uint32_t chip_id, enum OpalLPCAddressType addr_type,
uint32_t addr, __be32 *data, uint32_t sz);
-int64_t opal_read_elog(uint64_t buffer, size_t size, uint64_t log_id);
-int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t *elog_type);
+int64_t opal_read_elog(uint64_t buffer, uint64_t size, uint64_t log_id);
+int64_t opal_get_elog_size(uint64_t *log_id, uint64_t *size, uint64_t *elog_type);
int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
int64_t opal_send_ack_elog(uint64_t log_id);
void opal_resend_pending_logs(void);
@@ -866,13 +866,13 @@ int64_t opal_dump_read(uint32_t dump_id,
int64_t opal_dump_ack(uint32_t dump_id);
int64_t opal_dump_resend_notification(void);
-int64_t opal_get_msg(uint64_t buffer, size_t size);
-int64_t opal_check_completion(uint64_t buffer, size_t size, uint64_t token);
+int64_t opal_get_msg(uint64_t buffer, uint64_t size);
+int64_t opal_check_completion(uint64_t buffer, uint64_t size, uint64_t token);
int64_t opal_sync_host_reboot(void);
int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
- size_t length);
+ uint64_t length);
int64_t opal_set_param(uint64_t token, uint32_t param_id, uint64_t buffer,
- size_t length);
+ uint64_t length);
int64_t opal_sensor_read(uint32_t sensor_hndl, int token,
uint32_t *sensor_data);
Index: b/arch/powerpc/platforms/powernv/opal-elog.c
===================================================================
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -243,7 +243,7 @@ static struct elog_obj *create_elog_obj(
static void elog_work_fn(struct work_struct *work)
{
- size_t elog_size;
+ uint64_t elog_size;
uint64_t log_id;
uint64_t elog_type;
int rc;
^ permalink raw reply
* [PATCH 2/4] powerpc/powernv: Remove some OPAL function declaration duplication
From: Anton Blanchard @ 2014-03-27 5:19 UTC (permalink / raw)
To: stewart, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20140327161849.791432d0@kryten>
We had some duplication of the internal OPAL functions.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: b/arch/powerpc/include/asm/opal.h
===================================================================
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -877,7 +877,8 @@ int64_t opal_sensor_read(uint32_t sensor
uint32_t *sensor_data);
/* Internal functions */
-extern int early_init_dt_scan_opal(unsigned long node, const char *uname, int depth, void *data);
+extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
+ int depth, void *data);
extern int early_init_dt_scan_recoverable_ranges(unsigned long node,
const char *uname, int depth, void *data);
@@ -886,10 +887,6 @@ extern int opal_put_chars(uint32_t vterm
extern void hvc_opal_init_early(void);
-/* Internal functions */
-extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
- int depth, void *data);
-
extern int opal_notifier_register(struct notifier_block *nb);
extern int opal_message_notifier_register(enum OpalMessageType msg_type,
struct notifier_block *nb);
@@ -897,9 +894,6 @@ extern void opal_notifier_enable(void);
extern void opal_notifier_disable(void);
extern void opal_notifier_update_evt(uint64_t evt_mask, uint64_t evt_val);
-extern int opal_get_chars(uint32_t vtermno, char *buf, int count);
-extern int opal_put_chars(uint32_t vtermno, const char *buf, int total_len);
-
extern int __opal_async_get_token(void);
extern int opal_async_get_token_interruptible(void);
extern int __opal_async_release_token(int token);
@@ -907,8 +901,6 @@ extern int opal_async_release_token(int
extern int opal_async_wait_response(uint64_t token, struct opal_msg *msg);
extern int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data);
-extern void hvc_opal_init_early(void);
-
struct rtc_time;
extern int opal_set_rtc_time(struct rtc_time *tm);
extern void opal_get_rtc_time(struct rtc_time *tm);
^ permalink raw reply
* [PATCH 3/4] powerpc/powernv: Fix little endian issues with opal_do_notifier calls
From: Anton Blanchard @ 2014-03-27 5:20 UTC (permalink / raw)
To: stewart, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20140327161849.791432d0@kryten>
The bitmap in opal_poll_events and opal_handle_interrupt is
big endian, so we need to byteswap it on little endian builds.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: b/arch/powerpc/platforms/powernv/opal.c
===================================================================
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -216,14 +216,14 @@ void opal_notifier_update_evt(uint64_t e
void opal_notifier_enable(void)
{
int64_t rc;
- uint64_t evt = 0;
+ __be64 evt = 0;
atomic_set(&opal_notifier_hold, 0);
/* Process pending events */
rc = opal_poll_events(&evt);
if (rc == OPAL_SUCCESS && evt)
- opal_do_notifier(evt);
+ opal_do_notifier(be64_to_cpu(evt));
}
void opal_notifier_disable(void)
@@ -501,7 +501,7 @@ static irqreturn_t opal_interrupt(int ir
opal_handle_interrupt(virq_to_hw(irq), &events);
- opal_do_notifier(events);
+ opal_do_notifier(be64_to_cpu(events));
return IRQ_HANDLED;
}
^ permalink raw reply
* [PATCH 4/4] powerpc/powernv: Fix little endian issues OPAL error log code
From: Anton Blanchard @ 2014-03-27 5:20 UTC (permalink / raw)
To: stewart, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20140327161849.791432d0@kryten>
Fix little endian issues with the OPAL error log code.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: b/arch/powerpc/platforms/powernv/opal-elog.c
===================================================================
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv/opal-elog.c
@@ -243,18 +243,25 @@ static struct elog_obj *create_elog_obj(
static void elog_work_fn(struct work_struct *work)
{
+ __be64 size;
+ __be64 id;
+ __be64 type;
uint64_t elog_size;
uint64_t log_id;
uint64_t elog_type;
int rc;
char name[2+16+1];
- rc = opal_get_elog_size(&log_id, &elog_size, &elog_type);
+ rc = opal_get_elog_size(&id, &size, &type);
if (rc != OPAL_SUCCESS) {
pr_err("ELOG: Opal log read failed\n");
return;
}
+ elog_size = be64_to_cpu(size);
+ log_id = be64_to_cpu(id);
+ elog_type = be64_to_cpu(type);
+
BUG_ON(elog_size > OPAL_MAX_ERRLOG_SIZE);
if (elog_size >= OPAL_MAX_ERRLOG_SIZE)
Index: b/arch/powerpc/include/asm/opal.h
===================================================================
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -851,7 +851,7 @@ int64_t opal_lpc_read(uint32_t chip_id,
uint32_t addr, __be32 *data, uint32_t sz);
int64_t opal_read_elog(uint64_t buffer, uint64_t size, uint64_t log_id);
-int64_t opal_get_elog_size(uint64_t *log_id, uint64_t *size, uint64_t *elog_type);
+int64_t opal_get_elog_size(__be64 *log_id, __be64 *size, __be64 *elog_type);
int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
int64_t opal_send_ack_elog(uint64_t log_id);
void opal_resend_pending_logs(void);
^ permalink raw reply
* Re: [PATCH v4] powernv: Dynamic Frequency Scaling Enablement
From: Viresh Kumar @ 2014-03-27 5:38 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Linux PM list, linuxppc-dev@ozlabs.org, Anton Blanchard,
Srivatsa S. Bhat
In-Reply-To: <1395852947-22290-1-git-send-email-ego@linux.vnet.ibm.com>
On 26 March 2014 22:25, Gautham R. Shenoy <ego@linux.vnet.ibm.com> wrote:
> This is the v4 of the patchset to enable Dynamic Frequency Scaling
> on IBM PowerNV Platforms. I have incorporated the review comments
> from the previous version (can be found at [1]).
I wouldn't have added a cover-letter if I only have a single patch to
send. Would have rather used the not-to-be-commited field of the
patch instead.
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/powernv: Use uint64_t instead of size_t in OPAL APIs
From: Stewart Smith @ 2014-03-27 5:54 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20140327161849.791432d0@kryten>
Anton Blanchard <anton@samba.org> writes:
> Using size_t in our APIs is asking for trouble, especially
> when some OPAL calls use size_t pointers.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Reviewed-by: Stewart Smith <stewart@linux.vnet.ibm.com>
> ---
>
> Index: b/arch/powerpc/include/asm/opal.h
> ===================================================================
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -850,8 +850,8 @@ int64_t opal_lpc_write(uint32_t chip_id,
> int64_t opal_lpc_read(uint32_t chip_id, enum OpalLPCAddressType addr_type,
> uint32_t addr, __be32 *data, uint32_t sz);
>
> -int64_t opal_read_elog(uint64_t buffer, size_t size, uint64_t log_id);
> -int64_t opal_get_elog_size(uint64_t *log_id, size_t *size, uint64_t *elog_type);
> +int64_t opal_read_elog(uint64_t buffer, uint64_t size, uint64_t log_id);
> +int64_t opal_get_elog_size(uint64_t *log_id, uint64_t *size, uint64_t *elog_type);
> int64_t opal_write_elog(uint64_t buffer, uint64_t size, uint64_t offset);
> int64_t opal_send_ack_elog(uint64_t log_id);
> void opal_resend_pending_logs(void);
> @@ -866,13 +866,13 @@ int64_t opal_dump_read(uint32_t dump_id,
> int64_t opal_dump_ack(uint32_t dump_id);
> int64_t opal_dump_resend_notification(void);
>
> -int64_t opal_get_msg(uint64_t buffer, size_t size);
> -int64_t opal_check_completion(uint64_t buffer, size_t size, uint64_t token);
> +int64_t opal_get_msg(uint64_t buffer, uint64_t size);
> +int64_t opal_check_completion(uint64_t buffer, uint64_t size, uint64_t token);
> int64_t opal_sync_host_reboot(void);
> int64_t opal_get_param(uint64_t token, uint32_t param_id, uint64_t buffer,
> - size_t length);
> + uint64_t length);
> int64_t opal_set_param(uint64_t token, uint32_t param_id, uint64_t buffer,
> - size_t length);
> + uint64_t length);
> int64_t opal_sensor_read(uint32_t sensor_hndl, int token,
> uint32_t *sensor_data);
>
> Index: b/arch/powerpc/platforms/powernv/opal-elog.c
> ===================================================================
> --- a/arch/powerpc/platforms/powernv/opal-elog.c
> +++ b/arch/powerpc/platforms/powernv/opal-elog.c
> @@ -243,7 +243,7 @@ static struct elog_obj *create_elog_obj(
>
> static void elog_work_fn(struct work_struct *work)
> {
> - size_t elog_size;
> + uint64_t elog_size;
> uint64_t log_id;
> uint64_t elog_type;
> int rc;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox