On Mon, 2015-03-30 at 16:46 -0700, Joe Perches wrote:
> Use the normal return values for bool functions
Acked-by: Benjamin Herrenschmidt
Should we merge it or will you ?
Cheers,
Ben.
> Signed-off-by: Joe Perches
> ---
> arch/powerpc/include/asm/dcr-native.h| 2 +-
> arch/
On Tue, 2015-03-31 at 14:06 -0400, Sowmini Varadhan wrote:
> Having bravely said that..
>
> the IB team informs me that they see a 10% degradation using
> the spin_lock as opposed to the trylock.
>
> one path going forward is to continue processing this patch-set
> as is. I can investigate this
On Wed, 2015-04-01 at 14:56 +0800, Jeremy Kerr wrote:
> Hi Michael,
>
> > Let's try something different.
> >
> > This prints:
> >
> > Quiescing Open Firmware ...
> > Booting Linux via __start() ...
>
> "returning from prom_init" has been an emblem of the powerpc kernel boot
> since old time
On Thu, 2015-04-02 at 12:21 -0400, David Miller wrote:
> From: Sowmini Varadhan
> Date: Thu, 2 Apr 2015 08:51:52 -0400
>
> > do I need to resubmit this without the RFC tag? Perhaps I should
> > have dropped that some time ago.
>
> I want to hear from the powerpc folks whether they can positively
On Fri, 2015-04-03 at 07:22 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2015-04-02 at 12:21 -0400, David Miller wrote:
> > From: Sowmini Varadhan
> > Date: Thu, 2 Apr 2015 08:51:52 -0400
> >
> > > do I need to resubmit this without the RFC tag? Perhaps I shoul
On Tue, 2015-03-31 at 10:40 -0400, Sowmini Varadhan wrote:
> + if (largealloc) {
> + pool = &(iommu->large_pool);
> + spin_lock_irqsave(&pool->lock, flags);
> + pool_nr = 0; /* to keep compiler happy */
> + } else {
> + /* pick out pool_nr */
On Thu, 2015-04-02 at 17:43 -0400, Sowmini Varadhan wrote:
> On (04/03/15 07:54), Benjamin Herrenschmidt wrote:
> > > + limit = pool->end;
> > > +
> > > + /* The case below can happen if we have a small segment appended
> > > + * to a large, or when
On Fri, 2015-04-03 at 08:57 +1100, Benjamin Herrenschmidt wrote:
> No, the last argument to iommu_area_alloc() which is passed from the
> callers when doing consistent allocs. Basically, the DMA api mandates
> that consistent allocs are naturally aligned (to their own size), we
> im
On Fri, 2015-04-03 at 09:01 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2015-04-03 at 08:57 +1100, Benjamin Herrenschmidt wrote:
>
> > No, the last argument to iommu_area_alloc() which is passed from the
> > callers when doing consistent allocs. Basically, the DMA api
On Thu, 2015-04-02 at 17:54 -0400, Sowmini Varadhan wrote:
> the other question that comes to my mind is: the whole lazy_flush
> optimization probably works best when there is exactly one pool,
> and no large pools. In most other cases, we'd end up doing a lazy_flush
> when we wrap within our pool
On Thu, 2015-04-02 at 18:15 -0400, Sowmini Varadhan wrote:
> On (04/03/15 08:57), Benjamin Herrenschmidt wrote:
> >
> > > > I only just noticed too, you completely dropped the code to honor
> > > > the dma mask. Why that ? Some devices rely on this.
>
>
On Fri, 2015-04-03 at 14:28 -0400, Sowmini Varadhan wrote:
>
> Just want to confirm:
>
> > > + again:
> > > + if (pass == 0 && handle && *handle &&
> > > + (*handle >= pool->start) && (*handle < pool->end))
> > > + start = *handle;
> > > + else
> > > + start = pool->hint;
> >
On Sat, 2015-04-04 at 07:27 -0400, Sowmini Varadhan wrote:
> One last question before I spin out v9.. the dma_mask code
> is a bit confusing to me, so I want to make sure... the code is
>
> > if (limit + tbl->it_offset > mask) {
> > limit = mask - tbl->it_offset + 1;
> >
On Sun, 2015-04-05 at 07:49 -0400, Sowmini Varadhan wrote:
> + if (likely(pass == 0)) {
> + /* First failure, rescan from the beginning.
> */
> + pool->hint = pool->start;
> + set_flush(iommu);
> +
On Tue, 2015-04-07 at 20:03 +0200, Cedric Le Goater wrote:
>
> This is a shortcut. The code is for the ibmpowernv platform and assumes
> that we are running on a P8 (8 hardware threads). It would be better to
> use a "maximum threads per core" variable but I am not sure this is
> available, as
to completely make the BAR looks like
it's prefetchable when it's not.
Cheers,
Ben.
> Signed-off-by: Yinghai Lu
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Gavin Shan
> Cc: Yijing Wang
> Cc: Anton Blanchard
> Cc: linu
On Tue, 2015-04-07 at 22:39 -0700, Yinghai Lu wrote:
> On Tue, Apr 7, 2015 at 8:49 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2015-04-07 at 17:24 -0700, Yinghai Lu wrote:
> >> For device resource PREF bit setting under bridge 64-bit pref resource,
> >> we need
appy with your last version, feel free to add my
Acked-by: Benjamin Herrenschmidt
I'll port powerpc over when I get a chance and if I find a need to tweak
something at that point, I'll send a separate patch on top of yours.
Cheers,
Ben.
> Signed-off-by: Sowmini Varadhan
> ---
>
On Sat, 2015-04-25 at 17:31 +1000, Alexey Kardashevskiy wrote:
> We need BAR setup in 2 cases: when SLOF needs to boot from a PCI device
> (and SLOF can do BAR setup) and when we do PCI hotplug - and BARs are set
> by the guest, otherwise we hit races here (Michael Roth can tell more). So
> as f
On Thu, 2015-04-23 at 16:13 +0200, Jacek Anaszewski wrote:
> How the firmware is related to kernel? These bindings are for kernel,
> not for the firmware.
There should be no relation. DT bindings should be kernel agnostic and
represent the HW layout, not be designed based on what a given kernel
d
On Fri, 2015-04-24 at 12:15 +0200, Jacek Anaszewski wrote:
> No matter what format of device tree OPAL produces, I assume that
> it must compile it from some sources.
Nope. Well... .C code maybe qualifies as "sources" :-)
> dtb file is a compiled form of human readable dts file containing
> Flatt
On Mon, 2015-04-27 at 09:24 +0200, Jacek Anaszewski wrote:
> I was not aware that some other entity than the driver could be
> interested in the information provided by DT node. I will no longer
> object, provided that we will get an ack from DT maintainer.
My understanding is that we no longer ne
On Mon, 2015-04-27 at 11:32 +0200, Thomas Huth wrote:
> Anyway, I think we can fix that up as soon as somebody tries to run
> the
> js2x code again (I still have a YDL PowerStation at home somewhere,
> maybe I will have enough spare time to reactivate it one day).
>
> And since your changes itself
On Wed, 2015-04-01 at 14:07 +0800, Jeremy Kerr wrote:
> This change adds a char device to access the "PRD" (processor runtime
> diagnostics) channel to OPAL firmware.
>
> Includes contributions from Vaidyanathan Srinivasan, Neelesh Gupta &
> Vishal Kulkarni.
>
> Signed-off-by: Neelesh Gupta
> Si
On Thu, 2015-04-30 at 19:33 +1000, Alexey Kardashevskiy wrote:
> On 04/30/2015 05:22 PM, David Gibson wrote:
> > On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
> >> At the moment only one group per container is supported.
> >> POWER8 CPUs have more flexible design and allows
On Fri, 2015-05-01 at 11:46 +0800, Jeremy Kerr wrote:
> Hi Ben,
>
> >> +static LIST_HEAD(opal_prd_msg_queue);
> >> +static DEFINE_SPINLOCK(opal_prd_msg_queue_lock);
> >> +static DECLARE_WAIT_QUEUE_HEAD(opal_prd_msg_wait);
> >> +static atomic_t usage;
> >
> > opal_prd_usage ... otherwise it's a m
On Fri, 2015-05-01 at 07:54 -0500, Rob Herring wrote:
> The difference seems to be whether you allocate space or just point to
> the FDT for various strings/data. Is that right?
>
> >* of_fdt_add_subtree() is the introduced API to do the work.
>
> Have you looked at overlays and if so why do
On Fri, 2015-05-01 at 13:46 -0500, Rob Herring wrote:
> On Fri, May 1, 2015 at 10:22 AM, Benjamin Herrenschmidt
> wrote:
> > On Fri, 2015-05-01 at 07:54 -0500, Rob Herring wrote:
> >
> >> The difference seems to be whether you allocate space or just point to
> >&
On Sat, 2015-05-02 at 08:57 +1000, Benjamin Herrenschmidt wrote:
> > Overlay = an FDT blob to graft into a live running system. Sounds like
> > the same thing.
> >
> > > As for the details of Gavin implementation, I haven't looked at it in
> > > d
On Sat, 2015-05-02 at 09:29 +1000, Benjamin Herrenschmidt wrote:
> Looking a bit more at it, I don't quite see how I can attach a subtree
> using that stuff.
>
> Instead, each node in the overlay seems to need extra nodes and
> properties to refer to the original.
On Mon, 2015-05-04 at 11:30 +1000, Gavin Shan wrote:
> Thanks, Ben. If we really need utilize overlay to support our case,
> we need some one to parse the input (device-tree changes) from
> firmware
> and create "overlay" device node and "target" node as I mentioned
> above.
> It's not simpler than
On Mon, 2015-05-04 at 19:41 +0300, Pantelis Antoniou wrote:
>
> You get all of the corner cases handled for free. Perhaps it works for
> your case too.
>
> Perhaps you can educate me on what you need supported and we can make
> sure it’s included.
Which corner cases ?
IE, what I want is simply
On Thu, 2015-05-07 at 12:46 +0530, Aneesh Kumar K.V wrote:
> We need to check whether pte is present in follow_huge_addr and
> properly return NULL if mapping is not present. Also use READ_ONCE
> when dereferencing pte_t address.
Do that need to go to stable as well ?
> Signed-off-by: Aneesh Kuma
On Sun, 2015-05-10 at 21:32 +0300, Aaro Koskinen wrote:
> Hi,
>
> With 4.1-rc2 the rackmeter driver for G5 Xserve is giving bogus
> led patterns. So far I have seen at least the following:
>
> a) With static load the leds seems to be sane and report CPU
> usage properly, but after few minutes the
On Sun, 2015-05-10 at 20:34 +0200, Wolfram Sang wrote:
> Okay, so this patch is bogus. I understand now that onyx uses another
> codec than TAS, so this change will regress on other machines.
> However,
> it shows that this unconditional instantiation of the TAS breaks sound
> on Macintoshs which s
On Mon, 2015-05-11 at 09:34 +0200, w...@the-dreams.de wrote:
> On Mon, May 11, 2015 at 08:14:47AM +1000, Benjamin Herrenschmidt wrote:
> > On Sun, 2015-05-10 at 20:34 +0200, Wolfram Sang wrote:
> > > Okay, so this patch is bogus. I understand now that onyx uses another
> &
On Tue, 2015-05-12 at 20:55 +0300, Aaro Koskinen wrote:
> I'm running with HZ=100 so the values are still probably within
> jiffy resolution, so perhaps the calculation should first do
> idle = min(idle, total)?
Does it gives you a reasonable output if you do that ?
Cheers,
Ben.
___
On Tue, 2015-05-12 at 17:07 -0500, Brian King wrote:
> The mpt2sas driver was changed late last year in that it now requests a 64
> bit DMA
> mask, then requests a 32 bit coherent DMA mask, then later requests a 64 bit
> coherent
> DMA mask. This was 5fb1bf8aaa832e1e9ca3198de7bbecb8eff7db9c. This
On Wed, 2015-05-13 at 22:14 +0530, Sreekanth Reddy wrote:
> Hi Brain,
>
> We had a restriction from the firmware that the upper 32 bits of the
> RDPQ pool entries must be same. So to limit this restriction we
> initially set the consistent DMA mask to 32 and then after allocating
> the RDPQ pools
On Tue, 2015-05-05 at 07:14 +1000, Benjamin Herrenschmidt wrote:
> So the "trivial" way to do it (and the way we have implemented the FW
> side so far) is to have the FW simply "flatten" the subtree below the
> slot and pass it to Linux, with the intent of expanding
On Wed, 2015-05-13 at 19:18 -0500, Rob Herring wrote:
> I haven't decided really.
>
> The main thing with the current patch is I don't really like the added
> complexity to unflatten_dt_node. It is already a fairly complex
> function. Perhaps removing of "hybrid" as discussed will help?
I agree,
On Thu, 2015-05-14 at 09:23 +0300, Pantelis Antoniou wrote:
> > A few things that I don't find in the overlay code (but maybe I haven't
> > looked at it hard enough):
> >
> > - Can it remove nodes/properties ?
> >
>
> Yes.
Ok, I've missed that when looking at the overlay code then, I'll have t
On Thu, 2015-05-14 at 10:04 +0300, Pantelis Antoniou wrote:
> Hmm, since you just want to transmit a whole subtree things are a bit
> simpler.
>
> You don’t need any of the fixups, and your target node is known.
>
> So your overlay is simply:
>
> / {
> fragment@0 {
> target-
On Thu, 2015-05-14 at 10:19 +0300, Pantelis Antoniou wrote:
>
> You don’t want to know how sausages are made, but they are delicious :)
... most of the time :)
> > But yeah generating the overlay doesn't necessarily scare me, I can
> > generate a temp tree that is the overlay in which I "copy"
> So I would have to do a special case on unplug:
>
> if (slot->dt_is_overlay) /* set to false at boot */
> remove_subtree_myself();
> else
> undo_overlay(slot->overlay);
Of course I just inverted the polarity of the if () in the example :-)
But you get t
This patch adds the ability to the DMA direct ops to fallback to the IOMMU
ops for coherent alloc/free if the coherent mask of the device isn't
suitable for accessing the direct DMA space and the device also happens
to have an active IOMMU table.
Signed-off-by: Benjamin Herrenschmidt
---
On Thu, 2015-05-14 at 10:34 +0300, Pantelis Antoniou wrote:
> >> What you describe is inserting a bunch of properties and nodes under
> >> a slot’s device node. Reverting the overlay removes them all just fine.
> >
> > Except that still doesn't work for boot time :-)
> >
> > So I would have to d
On Thu, 2015-05-14 at 13:06 +0300, Aaro Koskinen wrote:
> Hi,
>
> On Wed, May 13, 2015 at 06:39:40AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2015-05-12 at 20:55 +0300, Aaro Koskinen wrote:
> > > I'm running with HZ=100 so the values are still probably with
This patch adds the ability to the DMA direct ops to fallback to the IOMMU
ops for coherent alloc/free if the coherent mask of the device isn't
suitable for accessing the direct DMA space and the device also happens
to have an active IOMMU table.
Signed-off-by: Benjamin Herrenschmidt
--
This patch adds the ability to the DMA direct ops to fallback to the IOMMU
ops for coherent alloc/free if the coherent mask of the device isn't
suitable for accessing the direct DMA space and the device also happens
to have an active IOMMU table.
Signed-off-by: Benjamin Herrenschmidt
--
On Thu, 2015-05-14 at 14:02 +0300, Pantelis Antoniou wrote:
> Hi Ben,
>
> > On May 14, 2015, at 10:47 , Benjamin Herrenschmidt
> > wrote:
> >
>
> [snip]
>
> So I spend some time thinking about your use case and I think it boils down
> to this:
>
&g
This patch adds the ability to the DMA direct ops to fallback to the IOMMU
ops for coherent alloc/free if the coherent mask of the device isn't
suitable for accessing the direct DMA space and the device also happens
to have an active IOMMU table.
Signed-off-by: Benjamin Herrenschmidt
Test
On Tue, 2015-05-26 at 15:10 +1000, Anton Blanchard wrote:
> When we take a PMU exception or a software event we call
> perf_read_regs(). This overloads regs->result with a boolean that
> describes if we should use the sampled instruction address register
> (SIAR) or the regs.
>
> If the exception
On Thu, 2015-05-28 at 15:08 -0700, Yinghai Lu wrote:
> On Wed, May 27, 2015 at 6:30 PM, Rafael J. Wysocki wrote:
> > On Wednesday, May 27, 2015 02:31:49 PM Bjorn Helgaas wrote:
> > For debug you can always use pcie_ports=compat and that will disable
> > pciehp too.
>
> That will disable AER at th
On Sat, 2015-05-30 at 11:31 +0530, Vaidyanathan Srinivasan wrote:
> In shared lpar case, spinning in guest context may potentially take
> away cycles from other lpars waiting to run on the same physical cpu.
>
> So the policy in shared lpar case is to let PowerVM hypervisor know
> immediately that
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> Apologies for hijacking this thread but I need to extend this discussion
> somewhat regarding what a compiler might do with adjacent fields in a
> structure.
>
> The tty subsystem defines a large aggregate structure, struct tty_struct.
> I
Hi folks !
I've been tracking down some problems with the recent DRI on powerpc and
stumbled upon something that doesn't look right, and not necessarily
only for us.
Now it's possible that I haven't fully understood the code here and I
also don't know to what extent some of that behaviour is nece
On Wed, 2014-09-03 at 21:55 -0400, Jerome Glisse wrote:
> So i think we need to get a platform flags and or set_pages_array_wc|uc
> needs to fail and this would fallback to cached mapping if the fallback
> code still works. So if your arch properly return and error for those
> cache changing functi
On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> So in the meantime the attached patch should work, it just silently ignore
> the caching attribute request on non x86 instead of pretending that things
> are setup as expected and then latter the radeon ou nouveau hw unsetting
> the snoop b
On Wed, 2014-09-03 at 22:36 -0400, Jerome Glisse wrote:
> On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
> > On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
> > >
>
On Thu, 2014-09-04 at 16:19 +0900, Michel Dänzer wrote:
> > +#else /* CONFIG_X86 */
> > +int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
> *placement)
> > +{
> > + if (*placement & (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
> > + ttm->caching_state = tt_cached;
> > +
On Thu, 2014-09-04 at 09:44 +0200, Thomas Hellstrom wrote:
> > This will, from what I can tell, try to use the same caching mode as the
> > original object:
> >
> > if ((cur_placement & caching) != 0)
> > result |= (cur_placement & caching);
> >
> > And cur_placement comes from bo-
On Thu, 2014-09-04 at 16:59 +0900, Michel Dänzer wrote:
>
> Define 'not reliably'. I have uptimes of weeks, and I'm pretty sure I'm
> not alone, at least with AGP 1x it seems to work quite well for most
> people. So I don't see the justification for intentionally breaking it
> completely for al
On Thu, 2014-09-04 at 11:34 +0200, Daniel Vetter wrote:
> On Thu, Sep 04, 2014 at 09:44:04AM +0200, Thomas Hellstrom wrote:
> > Last time I tested, (and it seems like Michel is on the same track),
> > writing with the CPU to write-combined memory was substantially faster
> > than writing to cached
On Thu, 2014-09-04 at 08:43 +, David Laight wrote:
> From: Benjamin Herrenschmidt
> > On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
> >
> > > Apologies for hijacking this thread but I need to extend this discussion
> > > somewhat regarding what
On Mon, 2014-09-15 at 14:22 +0530, Preeti U Murthy wrote:
> > We were talking about getting rid of powersave_nap altogether, but I
> think we
> > decided we couldn't, I forget.
>
> Isn't this a helpful knob to disable cpuidle at runtime? Currently we
> check the value of powersave_nap before enter
On Mon, 2014-09-15 at 13:10 +1000, Michael Ellerman wrote:
> > +enum OpalCheckTokenStatus {
> > + OPAL_TOKEN_ABSENT = 0,
> > + OPAL_TOKEN_PRESENT = 1
> > +};
>
> I don't see this used anywhere?
>
> And NoCamelCase !
>
> Yes I know there's lots in that file, but I didn't merge that :)
On Wed, 2014-09-24 at 12:22 +1000, Anton Blanchard wrote:
> Hi Steve,
>
> > > This could be broken from the earlier patches, I haven't run just
> > > this test. I probably should on them.
> >
> > I went back and tested, and it breaks under the first patch.
>
> Thanks for testing. It looks like s
On Thu, 2014-09-25 at 17:24 +1000, Gavin Shan wrote:
> When using bypass window on IODA2, the incorrect DMA operations
> "dma_iommu_ops" is used by devices. The device driver calls
> dma_get_required_mask() to determine using 32-bits or 64-bits
> bypass DMA window. Unfortunately, the returned DMA m
flag to struct pci_dev instead and adjusts the
corresponding arch/powerpc code to look for it there. At this point,
there is no attempt at making other architectures honor it just yet
though from what I can tell, x86 seems to always use 32-bit addresses
for MSIs.
Signed-off-by: Benjamin Herrenschmidt
well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.
This moves the setting of the quirk flag to the radeon driver
Signed-off-by: Benjamin Herrenschmidt
CC:
---
arch/powerpc/kernel/pci_64.c| 1 -
drivers/gpu/drm/radeon/radeon_irq_
h can use high bits
in the DMA address to distinguish between DMA windows.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
sound/pci/hda/hda_intel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 3e6d22d..2b679d5 1
well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.
This moves the setting of the quirk flag to the HDA driver when
detecting the radeon audio interface.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
arch/powerpc/kernel/pci_64.c | 6 --
On Wed, 2014-10-01 at 16:47 +1000, Michael Ellerman wrote:
>
> If we give it a name that says what it does, we get
> copro_get_ea_esid_and_vsid().
> Or something equally ugly.
copro_calc_full_va() ?
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lis
On Wed, 2014-10-01 at 09:38 +0200, Takashi Iwai wrote:
> > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > index 3e6d22d..2b679d5 100644
> > --- a/sound/pci/hda/hda_intel.c
> > +++ b/sound/pci/hda/hda_intel.c
> > @@ -297,7 +297,7 @@ enum {
> > /* quirks for ATI/AMD HDMI */
On Wed, 2014-10-01 at 17:41 +1000, Benjamin Herrenschmidt wrote:
> I don't like that approach because technically the chip doesn't do
> 64-bit DMA ... it does something like 40 or 48 (might actually depend on
> the chip version) and for all I know it will break on future x86 wi
On Wed, 2014-10-01 at 13:58 -0400, Alex Deucher wrote:
> Patch looks good. Audio DMAs are limited to 40 bits, same as the GPU
> side. I'm still waiting to hear back on the MSIs for audio, but they
> probably follow the GPU side, so I expect they should be fixed on Sea
> Islands as well.
In the a
On Wed, 2014-10-01 at 14:33 -0600, Bjorn Helgaas wrote:
> I like the idea of handling this more generically, e.g., with a bit like
> this in struct pci_dev (I'd probably name it something like "no_64bit_msi"
> along the lines of your driver #defines).
>
> What I don't like is that we haven't done
On Thu, 2014-10-02 at 08:08 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2014-10-01 at 13:58 -0400, Alex Deucher wrote:
> > Patch looks good. Audio DMAs are limited to 40 bits, same as the GPU
> > side. I'm still waiting to hear back on the MSIs for audio, but they
> &g
and adjusts the
corresponding arch/powerpc code to look for it there. At this point,
there is no attempt at making other architectures honor it just yet,
though it appears that x86 doesn't care and always generates 32-bit
MSI addresses.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
v2: Rename flag
well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.
This moves the setting of the quirk flag to the radeon driver
Signed-off-by: Benjamin Herrenschmidt
CC:
---
v2: This is just adjusted to the new flag name
arch/powerpc/kernel/pci
rs as the graphics drivers does.
Signed-off-by: Takashi Iwai
Signed-off-by: Benjamin Herrenschmidt
CC:
---
Tested, works fine. This patch is actually independent of the rest
of the series
sound/pci/hda/hda_intel.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --
irk all
the ATI HDMI for now. The consequences are nil on x86 anyway.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
arch/powerpc/kernel/pci_64.c | 6 --
sound/pci/hda/hda_intel.c| 10 --
sound/pci/hda/hda_priv.h | 1 +
3 files changed, 9 insertions(+), 8 deletions(-)
di
well, this is better
put under control of the drivers who know precisely what a given
HW revision can do.
This moves the setting of the quirk flag to the radeon driver
Signed-off-by: Benjamin Herrenschmidt
---
v2: This is just adjusted to the new flag name
arch/powerpc/kernel/pci_64.c
and adjusts the
corresponding arch/powerpc code to look for it there. At this point,
there is no attempt at making other architectures honor it just yet,
though it appears that x86 doesn't care and always generates 32-bit
MSI addresses.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
v2: Rename f
On Thu, 2014-10-02 at 09:59 +0200, Takashi Iwai wrote:
> > The attached updated patch only flags the affected asics.
>
> Alex's patch looks more comprehensive. For either patch,
>
> Reviewed-by: Takashi Iwai
Absolutely. I'll give it a spin tomorrow to be 100% sure. From there,
it will need th
On Thu, 2014-10-02 at 20:28 +1000, Ian Munsie wrote:
> Hey Michael,
>
> Excerpts from Michael Ellerman's message of 2014-10-02 16:02:37 +1000:
> > > +/* ioctls */
> > > +struct cxl_ioctl_start_work {
> > > +__u64 wed;
> > > +__u64 amr;
> > > +__u64 reserved1;
> > > +__u32 reserved2
ere isn't more
I can do generically. But ok, I'll do it that way.
> > Signed-off-by: Benjamin Herrenschmidt
> > CC:
> > ---
> >
> > v2: Rename flag to "no_64bit_msi" as suggested by Bjorn
> >
> > arch/powerpc/include/asm/pci-bridge
On Thu, 2014-10-02 at 09:34 -0600, Bjorn Helgaas wrote:
> On Thu, Oct 02, 2014 at 10:34:22AM +1000, Benjamin Herrenschmidt wrote:
> >
> > A number of radeon cards have a HW limitation causing them to be
> > unable to generate the full 64-bit of address bits for MSIs. This
&g
On Thu, 2014-10-02 at 14:13 -0700, Nishanth Aravamudan wrote:
> Ben & Michael,
>
> What's the status of these patches?
Waiting for somebody to review them ? :-)
Cheers,
Ben.
> Thanks,
> Nish
>
> On 27.08.2014 [17:33:59 +0800], Li Zhong wrote:
> > With commit 2fabf084b6ad ("powerpc: reorder per
On Thu, 2014-10-02 at 15:41 +0100, Romeo Cane wrote:
> Declaring sys_call_table as a pointer causes the compiler to generate the
> wrong lookup code in arch_syscall_addr
Care to elaborate ?
Ben.
> Signed-off-by: Romeo Cane
> ---
> arch/powerpc/include/asm/syscall.h | 2 +-
> 1 file changed, 1
On Thu, 2014-10-02 at 15:44 -0600, Bjorn Helgaas wrote:
> On Thu, Oct 2, 2014 at 3:02 PM, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2014-10-02 at 09:34 -0600, Bjorn Helgaas wrote:
> >> On Thu, Oct 02, 2014 at 10:34:22AM +1000, Benjamin Herrenschmidt wrote:
> >> >
On Thu, 2014-10-02 at 14:53 -0700, Nishanth Aravamudan wrote:
> On 03.10.2014 [07:28:19 +1000], Benjamin Herrenschmidt wrote:
> > On Thu, 2014-10-02 at 14:13 -0700, Nishanth Aravamudan wrote:
> > > Ben & Michael,
> > >
> > > What's the status of th
On Wed, 2014-10-01 at 22:13 -0400, Alex Deucher wrote:
> The attached updated patch only flags the affected asics.
I need formal (email :-) permission to add your s-o-b (and From: while
at it since you wrote most of it) for this patch. I'll then include
it in my new series.
Cheers,
Ben.
__
When reading from the LPC, the OPAL FW calls return the value via pointer
to a uint32_t which is always returned big endian. Our internal inb/outb
implementation byteswaps that fine but our debugfs code is still broken.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
diff --git a/arch/powerpc
On Fri, 2014-10-03 at 17:36 +1000, Michael Ellerman wrote:
> It seems that the only detail we are abstracting here is that power7 has 128
> TLB sets and power8 has 512. Is that right?
Today ...
> It seems like a lot of code to deal with that one detail.
>
> I guess the other thing it does is cur
e
AMD/ATI controllers as the graphics drivers does.
Signed-off-by: Takashi Iwai
Signed-off-by: Benjamin Herrenschmidt
CC:
---
sound/pci/hda/hda_intel.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
This is now fully replaced with the generic "no_64bit_msi" one
that is set by the respective drivers directly.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/pci-bridge.h | 2 --
arch/powerpc/kernel/pci_64.c | 10 --
2 files changed, 12 deletion
he current driver, so let's quirk all
the ATI HDMI for now. The consequences are nil on x86 anyway.
Signed-off-by: Alex Deucher
Signed-off-by: Benjamin Herrenschmidt
CC:
---
sound/pci/hda/hda_intel.c | 96 +--
sound/pci/hda/hda_priv.h | 1 +
Instead of the arch specific quirk which we are deprecating
and that drivers don't understand.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
arch/powerpc/platforms/pseries/msi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/msi.c
b
1 - 100 of 7623 matches
Mail list logo
