On Thu, 2014-01-16 at 13:47 +0800, hongbo.zh...@freescale.com wrote:
> From: Hongbo Zhang
>
> The usage of spin_lock_irqsave() is a stronger locking mechanism than is
> required throughout the driver. The minimum locking required should be used
> instead. Interrupts will be turned off and context
On Wed, Mar 26, 2014 at 8:47 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v3.14-rc8[1] to v3.14-rc7[3], the summaries are:
> - build errors: +6/-1
+ /scratch/kisskb/src/arch/powerpc/include/asm/io.h: error:
'virt_phys_offset' undeclared (first use in this function): =>
814:16, 807:1
On Tue, Mar 25, 2014 at 10:44:16PM +1100, Anton Blanchard wrote:
> The linker fixes up TOC. relocations, so prom_init_check.sh should
> ignore them.
Err, .TOC. you mean. Presumably something strips off the leading dot
somewhere?
> -btext_setup_display"
> +btext_setup_display TOC."
--
Alan Modr
From: Cody P Schafer
> On 03/25/2014 03:43 AM, Anton Blanchard wrote:
> >
> > Hi Cody,
> >
> > hv-24x7: could not obtain capabilities, error 0x
> fffe, not enabling
> > hv-gpci: could not obtain capabilities, error 0x
> fffe, not enabling
> >
> >> + pr_info("could n
On Tue, Mar 25, 2014 at 10:44:21PM +1100, Anton Blanchard wrote:
> Fix STK_PARAM and use it instead of hardcoding ABIv1 offsets.
> _GLOBAL(memcpy)
> BEGIN_FTR_SECTION
> - std r3,48(r1) /* save destination pointer for return value */
> + std r3,STK_PARAM(R3)(r1)/* save d
On Wed, Mar 26, 2014 at 08:34:49PM +1030, Alan Modra wrote:
> On Tue, Mar 25, 2014 at 10:44:21PM +1100, Anton Blanchard wrote:
> > Fix STK_PARAM and use it instead of hardcoding ABIv1 offsets.
>
> > _GLOBAL(memcpy)
> > BEGIN_FTR_SECTION
> > - std r3,48(r1) /* save destination pointer
On Tue, Mar 25, 2014 at 10:44:33PM +1100, Anton Blanchard wrote:
> From: Rusty Russell
> + case R_PPC64_REL16_HA:
> + /* Subtract location pointer */
> + value -= (unsigned long)location;
> + value = ((value + 0x8000) >> 16);
Hi Uli,
> You probably should have two different macros _GLOBAL_TOC vs. _GLOBAL
> (or _GLOBAL vs. _GLOBAL_NOTOC), and use the variant that provides a
> global entry point setting up the TOC only with those functions that
> actually require a TOC.
I was worried that we might introduce subtle bugs
It's quite cricial to clear error flags because SAI might hang if getting
FIFO underrun during playback (I haven't confirmed the same issue on Rx
overflow though).
So this patch enables those irq and adds isr() to clear the flags so as to
keep playback entirely safe.
Signed-off-by: Nicolin Chen
From: Nicolin Chen
> It's quite cricial to clear error flags because SAI might hang if getting
> FIFO underrun during playback (I haven't confirmed the same issue on Rx
> overflow though).
>
> So this patch enables those irq and adds isr() to clear the flags so as to
> keep playback entirely safe.
On 03/25/2014 11:22 AM, Anton Blanchard wrote:
Hi Vasant,
On 02/09/2014 02:50 AM, Anton Blanchard wrote:
Hi Vasant,
+static void free_dump_sg_list(struct opal_sg_list *list)
+{
+ struct opal_sg_list *sg1;
+ while (list) {
+ sg1 = list->next;
+ kfree(l
Unify the low/highmem code path from do_init_bootmem() by using (the)
lowmem related variables/parameters even when the low/highmem split
is not needed (64-bit) or configured. In such cases the "lowmem"
variables/parameters continue to observe the definition by referring
to memory directly mapped b
On 24.03.2014 [16:02:56 -0700], Nishanth Aravamudan wrote:
> In KVM guests on Power, if the guest is not backed by hugepages, we see
> the following in the guest:
>
> AnonHugePages: 0 kB
> HugePages_Total: 0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:
From: "Gautham R. Shenoy"
Hi,
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]).
In this version,
* Multiple patches from the previous version have been into a
From: Vaidyanathan Srinivasan
Backend driver to dynamically set voltage and frequency on
IBM POWER non-virtualized platforms. Power management SPRs
are used to set the required PState.
This driver works in conjunction with cpufreq governors
like 'ondemand' to provide a demand based frequency an
On Wed, 2014-03-26 at 14:45 +0800, Zhao Qiang wrote:
> The at8031 can work on polling mode and interrupt mode.
> Add ack_interrupt and config intr funcs to enable
> interrupt mode for it.
>
> Signed-off-by: Zhao Qiang
> ---
> drivers/net/phy/at803x.c | 30 ++
> 1 file
make the diu driver work without platform hooks.
So far the DIU driver does not have a mechanism to do the
board specific initialization. So on some platforms,
such as P1022, 8610 and 5121, The board specific initialization
is implmented in the platform file such p10222_ds.
This board sepecific i
For sleep, The diu module will power off and when
wake up for initialization will need.
Some platform such as the corenet plafrom does not provide
the DIU board sepecific initialization, but rely on the
DIU initializtion in u-boot. then the pixel clock resume will
be an issuel on this platform, Th
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.
You can't make it 100% abstract. The DIU driver requires some sort of
board support. I think you
On 03/26/2014 12:41 PM, Jason Jin wrote:
+ if (!diu_ops.set_pixel_clock) {
+ data->saved_pixel_clock = 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");
+
On Thu, 2014-02-20 at 18:30 +0200, Mihai Caraman wrote:
> diff --git a/arch/powerpc/kvm/book3s_paired_singles.c
> b/arch/powerpc/kvm/book3s_paired_singles.c
> index a59a25a..80c533e 100644
> --- a/arch/powerpc/kvm/book3s_paired_singles.c
> +++ b/arch/powerpc/kvm/book3s_paired_singles.c
> @@ -640,1
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 rathe
On Wed, Mar 26, 2014 at 11:59:53AM +, 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 trace
> + 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
On Thu, Mar 27, 2014 at 01:14:24AM +, Mark Brown wrote:
> On Wed, Mar 26, 2014 at 11:59:53AM +, 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 cle
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
> 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");
> > > +
> >
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 & FS
jason@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 exam
> jason@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 i
> 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_w
>
> On 03/26/2014 12:41 PM, Jason Jin wrote:
> > + if (!diu_ops.set_pixel_clock) {
> > + data->saved_pixel_clock = 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");
> >
> 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.
>
> You can't make it 100% abstract. The DIU driver requires some sort of
> board suppor
jason@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
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:
> > > > > >
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:
Te
> jason@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 fu
> > > > > > > + 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");
> > > > > > > +
> > >
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)
> > > >
> > So let's just ignore the clearance of these bits in isr().
> >
> > +
> > SAI Transmit Control Register (I2S1_TCSR) : 32 : R/W : _h
>
> 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
Using size_t in our APIs is asking for trouble, especially
when some OPAL calls use size_t pointers.
Signed-off-by: Anton Blanchard
---
Index: b/arch/powerpc/include/asm/opal.h
===
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/p
We had some duplication of the internal OPAL functions.
Signed-off-by: Anton Blanchard
---
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 @@
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
---
Index: b/arch/powerpc/platforms/powernv/opal.c
===
--- a/arch/powerpc/pla
Fix little endian issues with the OPAL error log code.
Signed-off-by: Anton Blanchard
---
Index: b/arch/powerpc/platforms/powernv/opal-elog.c
===
--- a/arch/powerpc/platforms/powernv/opal-elog.c
+++ b/arch/powerpc/platforms/powernv
On 26 March 2014 22:25, Gautham R. Shenoy 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
Anton Blanchard 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
Reviewed-by: Stewart Smith
> ---
>
> Index: b/arch/powerpc/include/asm/opal.h
> ===
Anton Blanchard writes:
> Fix little endian issues with the OPAL error log code.
>
> Signed-off-by: Anton Blanchard
Reviewed-by: Stewart Smith
Do we also need any magic for the getting of error logs themselves?
You may want to check the md5 of the logs themselves on be and le.
> ---
>
> Inde
On Tuesday 25 March 2014 11:06 PM, Kirill A. Shutemov wrote:
> On Tue, Mar 25, 2014 at 12:20:15PM +0530, Madhavan Srinivasan wrote:
>> Kirill A. Shutemov with the commit 96bacfe542 introduced
>> vm_ops->map_pages() for mapping easy accessible pages around
>> fault address in hope to reduce number o
The at8031 can work on polling mode and interrupt mode.
Add ack_interrupt and config intr funcs to enable
interrupt mode for it.
Signed-off-by: Zhao Qiang
---
drivers/net/phy/at803x.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/d
On Thu, 2014-03-27 at 11:08 +0530, Viresh Kumar wrote:
> On 26 March 2014 22:25, Gautham R. Shenoy 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])
Cc'ing Rafael.
On 26 March 2014 22:25, Gautham R. Shenoy wrote:
> From: Vaidyanathan Srinivasan
>
> Backend driver to dynamically set voltage and frequency on
> IBM POWER non-virtualized platforms. Power management SPRs
> are used to set the required PState.
>
> This driver works in conjunction
On 27 March 2014 11:58, Benjamin Herrenschmidt wrote:
> Any other comment ? :-)
Just gave on the patch..
> Because it depends on some other stuff in -next, I think it's best if
> this gets merged via Rafael's tree, unless someone can point me at
> the necessary pre-requisites in the form of a to
52 matches
Mail list logo
