* [Bug 98638] Panic on shutdown with AMDGPU and Ubuntu Plymouth
From: bugzilla-daemon @ 2016-11-14 11:28 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-98638-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 512 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98638
--- Comment #7 from Christian König <deathsimple@vodafone.de> ---
Try loading the amdgpu.ko module in gdb like this (Obviously please use the
correct one for your kernel version):
gdb /lib/modules/4.7.0+/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
And then run
l *(amdgpu_fence_wait_empty+0x2a)
This should give you a line number when debug symbols are available.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1301 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] broadcom/brcm80211/brcmfmac/cfg80211 driver, bad regulatory domain frequency value
From: Arend Van Spriel @ 2016-11-14 11:22 UTC (permalink / raw)
To: Gianfranco Costamagna, brcm80211-dev-list@broadcom.com,
linux-wireless@vger.kernel.org
Cc: nsmaldone@tierratelematics.com, Marco.Arlone@roj.com
In-Reply-To: <5474e850-1c52-c896-da9e-45720ed6d6ff@broadcom.com>
On 28-10-2016 22:41, Arend Van Spriel wrote:
> On 28-10-2016 18:15, Gianfranco Costamagna wrote:
>> (resending from my debian.org mail address, to avoid spam filtering)
>>
>> Hi Broadcom developers and linux wireless list.
>>
>> We found a possible issue in the cfg80211 implementation of the regulatory domain rules:
>>
>> .reg_rules = {
>> /* IEEE 802.11b/g, channels 1..11 */
>> REG_RULE(2412-10, 2472+10, 40, 6, 20, 0),
>>
>>
>> the referred channel 11 has/should have a frequency of 2462, not 2472 (corresponding to channel 13).
>> Is this a typo in the code or the above comment?
>>
>> (I'm not sure why the override of reg.c is in place for 2.4 Ghz frequencies)
>>
>> Can you please double check and in case apply the attached patch?
>
> checking.... stay tuned.
Hi Gianfranco,
Finally response. As it turns out the range was explcitly changed
enabling channels 12 and 13 to be used where applicable. They forgot to
update the comment.
Regards,
Arend
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau at arm.com @ 2016-11-14 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F90EA45@lhreml507-mbx>
On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> Hi Liviu
>
[snip]
> > > >
> > > > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and
> > you
> > > > actually need another variable for "reserving" an area in the I/O
> > space
> > > > that can be used for physical addresses rather than I/O tokens.
> > > >
> > > > The one good example for using PCIBIOS_MIN_IO is when your
> > > > platform/architecture
> > > > does not support legacy ISA operations *at all*. In that case
> > someone
> > > > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O
> > range
> > > > so that it doesn't get used. With Zhichang's patch you now start
> > > > forcing
> > > > those platforms to have a valid address below PCIBIOS_MIN_IO.
> > >
> > > But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be
> > used
> > > by PCI controllers only...
> >
> > Nope, that is not what it means. It means that PCI devices can see I/O
> > addresses
> > on the bus that start from 0. There never was any usage for non-PCI
> > controllers
>
> So I am a bit confused...
> From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
> I thought that was the reason why for most architectures we have
> PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
> usually use [0, PCIBIOS_MIN_IO - 1] )
First of all, cpu I/O addresses is an x86-ism. ARM architectures and others
have no separate address space for I/O, it is all merged into one unified
address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean
that we don't care about ISA I/O because the platform does not support having
an ISA bus (e.g.).
>
> For those architectures whose PCIBIOS_MIN_IO != 0x1000 probably
> they are not fully compliant or they cannot fully support an ISA
> controller...?
Exactly. Not fully compliant is a bit strong, as ISA is a legacy feature and
when it comes to PCI-e you are allowed to ignore it. Having PCIBIOS_MIN_IO != 0x1000
is a way to signal that you don't fully support ISA.
>
> As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
> to allow special ISA controllers to use that range with special
> accessors.
> Having a variable threshold would make life much more difficult
> as there would be a probe dependency between the PCI controller and
> the special ISA one (PCI to wait for the special ISA device to be
> probed and set the right threshold value from DT or ACPI table).
>
> Instead using PCIBIOS_MIN_IO is easier and should not impose much
> constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
> the PCI controller for I/O tokens...
What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves
space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve
space for your direct address I/O on top of PCIBIOS_MIN_IO.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
> > when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and
> > what
> > I think is not the right thing (and not enough anyway).
> >
> > > so if you have a special bus device using
> > > an I/O range in this case should be a PCI controller...
> >
> > That has always been the case. It is this series that wants to
> > introduce the
> > new meaning.
> >
> > > i.e. I would
> > > expect it to fall back into the case of I/O tokens redirection rather
> > than
> > > physical addresses redirection (as mentioned below from my previous
> > reply).
> > > What do you think?
> >
> > I think you have looked too much at the code *with* Zhichang's patches
> > applied.
> > Take a step back and look at how PCIBIOS_MIN_IO is used now, before you
> > apply
> > the patches. It is all about PCI addresses and there is no notion of
> > non-PCI
> > busses using PCI framework. Only platforms and architectures that try
> > to work
> > around some legacy standards (ISA) or HW restrictions.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > Thanks
> > >
> > > Gab
> > >
> > >
> > > >
> > > > For the general case you also have to bear in mind that
> > PCIBIOS_MIN_IO
> > > > could
> > > > be zero. In that case, what is your "forbidden" range? [0, 0) ? So
> > it
> > > > makes
> > > > sense to add a new #define that should only be defined by those
> > > > architectures/
> > > > platforms that want to reserve on top of PCIBIOS_MIN_IO another
> > region
> > > > where I/O tokens can't be generated for.
> > > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > >
> > > > > > > > Your current version has
> > > > > > > >
> > > > > > > > if (arm64_extio_ops->pfout)
> > > > \
> > > > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > > > >devpara,\
> > > > > > > > addr, value, sizeof(type));
> > > > \
> > > > > > > >
> > > > > > > > Instead, just subtract the start of the range from the
> > logical
> > > > > > > > port number to transform it back into a bus-local port
> > number:
> > > > > > >
> > > > > > > These accessors do not operate on IO tokens:
> > > > > > >
> > > > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end <
> > addr)
> > > > > > > addr is not going to be an I/O token; in fact patch 2/3
> > imposes
> > > > that
> > > > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > > > PCIBIOS_MIN_IO
> > > > > > > we have free physical addresses that the accessors can
> > operate
> > > > on.
> > > > > >
> > > > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to
> > refer
> > > > to
> > > > > > the logical I/O tokens, the purpose of that macro is really
> > meant
> > > > > > for allocating PCI I/O port numbers within the address space of
> > > > > > one bus.
> > > > >
> > > > > As I mentioned above, special devices operate on CPU addresses
> > > > directly,
> > > > > not I/O tokens. For them there is no way to distinguish....
> > > > >
> > > > > >
> > > > > > Note that it's equally likely that whichever next platform
> > needs
> > > > > > non-mapped I/O access like this actually needs them for PCI I/O
> > > > space,
> > > > > > and that will use it on addresses registered to a PCI host
> > bridge.
> > > > >
> > > > > Ok so here you are talking about a platform that has got an I/O
> > range
> > > > > under the PCI host controller, right?
> > > > > And this I/O range cannot be directly memory mapped but needs
> > special
> > > > > redirections for the I/O tokens, right?
> > > > >
> > > > > In this scenario registering the I/O ranges with the forbidden
> > range
> > > > > implemented by the current patch would still allow to redirect
> > I/O
> > > > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > > > >
> > > > > So effectively the special PCI host controller
> > > > > 1) knows the physical range that needs special redirection
> > > > > 2) register such range
> > > > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > > > special accessors
> > > > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in
> > 3)
> > > > >
> > > > > So to be honest I think this patch can fit well both with
> > > > > special PCI controllers that need I/O tokens redirection and with
> > > > > special non-PCI controllers that need non-PCI I/O physical
> > > > > address redirection...
> > > > >
> > > > > Thanks (and sorry for the long reply but I didn't know how
> > > > > to make the explanation shorter :) )
> > > > >
> > > > > Gab
> > > > >
> > > > > >
> > > > > > If we separate the two steps:
> > > > > >
> > > > > > a) assign a range of logical I/O port numbers to a bus
> > > > > > b) register a set of helpers for redirecting logical I/O
> > > > > > port to a helper function
> > > > > >
> > > > > > then I think the code will get cleaner and more flexible.
> > > > > > It should actually then be able to replace the powerpc
> > > > > > specific implementation.
> > > > > >
> > > > > > Arnd
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau @ 2016-11-14 11:26 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, Yuanzhichang,
mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F90EA45@lhreml507-mbx>
On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> Hi Liviu
>
[snip]
> > > >
> > > > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and
> > you
> > > > actually need another variable for "reserving" an area in the I/O
> > space
> > > > that can be used for physical addresses rather than I/O tokens.
> > > >
> > > > The one good example for using PCIBIOS_MIN_IO is when your
> > > > platform/architecture
> > > > does not support legacy ISA operations *at all*. In that case
> > someone
> > > > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O
> > range
> > > > so that it doesn't get used. With Zhichang's patch you now start
> > > > forcing
> > > > those platforms to have a valid address below PCIBIOS_MIN_IO.
> > >
> > > But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be
> > used
> > > by PCI controllers only...
> >
> > Nope, that is not what it means. It means that PCI devices can see I/O
> > addresses
> > on the bus that start from 0. There never was any usage for non-PCI
> > controllers
>
> So I am a bit confused...
> From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
> I thought that was the reason why for most architectures we have
> PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
> usually use [0, PCIBIOS_MIN_IO - 1] )
First of all, cpu I/O addresses is an x86-ism. ARM architectures and others
have no separate address space for I/O, it is all merged into one unified
address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean
that we don't care about ISA I/O because the platform does not support having
an ISA bus (e.g.).
>
> For those architectures whose PCIBIOS_MIN_IO != 0x1000 probably
> they are not fully compliant or they cannot fully support an ISA
> controller...?
Exactly. Not fully compliant is a bit strong, as ISA is a legacy feature and
when it comes to PCI-e you are allowed to ignore it. Having PCIBIOS_MIN_IO != 0x1000
is a way to signal that you don't fully support ISA.
>
> As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
> to allow special ISA controllers to use that range with special
> accessors.
> Having a variable threshold would make life much more difficult
> as there would be a probe dependency between the PCI controller and
> the special ISA one (PCI to wait for the special ISA device to be
> probed and set the right threshold value from DT or ACPI table).
>
> Instead using PCIBIOS_MIN_IO is easier and should not impose much
> constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
> the PCI controller for I/O tokens...
What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves
space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve
space for your direct address I/O on top of PCIBIOS_MIN_IO.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
> > when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and
> > what
> > I think is not the right thing (and not enough anyway).
> >
> > > so if you have a special bus device using
> > > an I/O range in this case should be a PCI controller...
> >
> > That has always been the case. It is this series that wants to
> > introduce the
> > new meaning.
> >
> > > i.e. I would
> > > expect it to fall back into the case of I/O tokens redirection rather
> > than
> > > physical addresses redirection (as mentioned below from my previous
> > reply).
> > > What do you think?
> >
> > I think you have looked too much at the code *with* Zhichang's patches
> > applied.
> > Take a step back and look at how PCIBIOS_MIN_IO is used now, before you
> > apply
> > the patches. It is all about PCI addresses and there is no notion of
> > non-PCI
> > busses using PCI framework. Only platforms and architectures that try
> > to work
> > around some legacy standards (ISA) or HW restrictions.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > Thanks
> > >
> > > Gab
> > >
> > >
> > > >
> > > > For the general case you also have to bear in mind that
> > PCIBIOS_MIN_IO
> > > > could
> > > > be zero. In that case, what is your "forbidden" range? [0, 0) ? So
> > it
> > > > makes
> > > > sense to add a new #define that should only be defined by those
> > > > architectures/
> > > > platforms that want to reserve on top of PCIBIOS_MIN_IO another
> > region
> > > > where I/O tokens can't be generated for.
> > > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > >
> > > > > > > > Your current version has
> > > > > > > >
> > > > > > > > if (arm64_extio_ops->pfout)
> > > > \
> > > > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > > > >devpara,\
> > > > > > > > addr, value, sizeof(type));
> > > > \
> > > > > > > >
> > > > > > > > Instead, just subtract the start of the range from the
> > logical
> > > > > > > > port number to transform it back into a bus-local port
> > number:
> > > > > > >
> > > > > > > These accessors do not operate on IO tokens:
> > > > > > >
> > > > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end <
> > addr)
> > > > > > > addr is not going to be an I/O token; in fact patch 2/3
> > imposes
> > > > that
> > > > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > > > PCIBIOS_MIN_IO
> > > > > > > we have free physical addresses that the accessors can
> > operate
> > > > on.
> > > > > >
> > > > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to
> > refer
> > > > to
> > > > > > the logical I/O tokens, the purpose of that macro is really
> > meant
> > > > > > for allocating PCI I/O port numbers within the address space of
> > > > > > one bus.
> > > > >
> > > > > As I mentioned above, special devices operate on CPU addresses
> > > > directly,
> > > > > not I/O tokens. For them there is no way to distinguish....
> > > > >
> > > > > >
> > > > > > Note that it's equally likely that whichever next platform
> > needs
> > > > > > non-mapped I/O access like this actually needs them for PCI I/O
> > > > space,
> > > > > > and that will use it on addresses registered to a PCI host
> > bridge.
> > > > >
> > > > > Ok so here you are talking about a platform that has got an I/O
> > range
> > > > > under the PCI host controller, right?
> > > > > And this I/O range cannot be directly memory mapped but needs
> > special
> > > > > redirections for the I/O tokens, right?
> > > > >
> > > > > In this scenario registering the I/O ranges with the forbidden
> > range
> > > > > implemented by the current patch would still allow to redirect
> > I/O
> > > > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > > > >
> > > > > So effectively the special PCI host controller
> > > > > 1) knows the physical range that needs special redirection
> > > > > 2) register such range
> > > > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > > > special accessors
> > > > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in
> > 3)
> > > > >
> > > > > So to be honest I think this patch can fit well both with
> > > > > special PCI controllers that need I/O tokens redirection and with
> > > > > special non-PCI controllers that need non-PCI I/O physical
> > > > > address redirection...
> > > > >
> > > > > Thanks (and sorry for the long reply but I didn't know how
> > > > > to make the explanation shorter :) )
> > > > >
> > > > > Gab
> > > > >
> > > > > >
> > > > > > If we separate the two steps:
> > > > > >
> > > > > > a) assign a range of logical I/O port numbers to a bus
> > > > > > b) register a set of helpers for redirecting logical I/O
> > > > > > port to a helper function
> > > > > >
> > > > > > then I think the code will get cleaner and more flexible.
> > > > > > It should actually then be able to replace the powerpc
> > > > > > specific implementation.
> > > > > >
> > > > > > Arnd
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau @ 2016-11-14 11:26 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, Yuanzhichang,
mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org,
kantyzc@163.com, linux-serial@vger.kernel.org,
catalin.marinas@arm.com, olof@lixom.net, bhelgaas@googl e.com,
zhichang.yuan02@gmail.com
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F90EA45@lhreml507-mbx>
On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> Hi Liviu
>
[snip]
> > > >
> > > > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and
> > you
> > > > actually need another variable for "reserving" an area in the I/O
> > space
> > > > that can be used for physical addresses rather than I/O tokens.
> > > >
> > > > The one good example for using PCIBIOS_MIN_IO is when your
> > > > platform/architecture
> > > > does not support legacy ISA operations *at all*. In that case
> > someone
> > > > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O
> > range
> > > > so that it doesn't get used. With Zhichang's patch you now start
> > > > forcing
> > > > those platforms to have a valid address below PCIBIOS_MIN_IO.
> > >
> > > But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be
> > used
> > > by PCI controllers only...
> >
> > Nope, that is not what it means. It means that PCI devices can see I/O
> > addresses
> > on the bus that start from 0. There never was any usage for non-PCI
> > controllers
>
> So I am a bit confused...
> From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
> I thought that was the reason why for most architectures we have
> PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
> usually use [0, PCIBIOS_MIN_IO - 1] )
First of all, cpu I/O addresses is an x86-ism. ARM architectures and others
have no separate address space for I/O, it is all merged into one unified
address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean
that we don't care about ISA I/O because the platform does not support having
an ISA bus (e.g.).
>
> For those architectures whose PCIBIOS_MIN_IO != 0x1000 probably
> they are not fully compliant or they cannot fully support an ISA
> controller...?
Exactly. Not fully compliant is a bit strong, as ISA is a legacy feature and
when it comes to PCI-e you are allowed to ignore it. Having PCIBIOS_MIN_IO != 0x1000
is a way to signal that you don't fully support ISA.
>
> As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
> to allow special ISA controllers to use that range with special
> accessors.
> Having a variable threshold would make life much more difficult
> as there would be a probe dependency between the PCI controller and
> the special ISA one (PCI to wait for the special ISA device to be
> probed and set the right threshold value from DT or ACPI table).
>
> Instead using PCIBIOS_MIN_IO is easier and should not impose much
> constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
> the PCI controller for I/O tokens...
What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves
space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve
space for your direct address I/O on top of PCIBIOS_MIN_IO.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
> > when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and
> > what
> > I think is not the right thing (and not enough anyway).
> >
> > > so if you have a special bus device using
> > > an I/O range in this case should be a PCI controller...
> >
> > That has always been the case. It is this series that wants to
> > introduce the
> > new meaning.
> >
> > > i.e. I would
> > > expect it to fall back into the case of I/O tokens redirection rather
> > than
> > > physical addresses redirection (as mentioned below from my previous
> > reply).
> > > What do you think?
> >
> > I think you have looked too much at the code *with* Zhichang's patches
> > applied.
> > Take a step back and look at how PCIBIOS_MIN_IO is used now, before you
> > apply
> > the patches. It is all about PCI addresses and there is no notion of
> > non-PCI
> > busses using PCI framework. Only platforms and architectures that try
> > to work
> > around some legacy standards (ISA) or HW restrictions.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > Thanks
> > >
> > > Gab
> > >
> > >
> > > >
> > > > For the general case you also have to bear in mind that
> > PCIBIOS_MIN_IO
> > > > could
> > > > be zero. In that case, what is your "forbidden" range? [0, 0) ? So
> > it
> > > > makes
> > > > sense to add a new #define that should only be defined by those
> > > > architectures/
> > > > platforms that want to reserve on top of PCIBIOS_MIN_IO another
> > region
> > > > where I/O tokens can't be generated for.
> > > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > >
> > > > > > > > Your current version has
> > > > > > > >
> > > > > > > > if (arm64_extio_ops->pfout)
> > > > \
> > > > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > > > >devpara,\
> > > > > > > > addr, value, sizeof(type));
> > > > \
> > > > > > > >
> > > > > > > > Instead, just subtract the start of the range from the
> > logical
> > > > > > > > port number to transform it back into a bus-local port
> > number:
> > > > > > >
> > > > > > > These accessors do not operate on IO tokens:
> > > > > > >
> > > > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end <
> > addr)
> > > > > > > addr is not going to be an I/O token; in fact patch 2/3
> > imposes
> > > > that
> > > > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > > > PCIBIOS_MIN_IO
> > > > > > > we have free physical addresses that the accessors can
> > operate
> > > > on.
> > > > > >
> > > > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to
> > refer
> > > > to
> > > > > > the logical I/O tokens, the purpose of that macro is really
> > meant
> > > > > > for allocating PCI I/O port numbers within the address space of
> > > > > > one bus.
> > > > >
> > > > > As I mentioned above, special devices operate on CPU addresses
> > > > directly,
> > > > > not I/O tokens. For them there is no way to distinguish....
> > > > >
> > > > > >
> > > > > > Note that it's equally likely that whichever next platform
> > needs
> > > > > > non-mapped I/O access like this actually needs them for PCI I/O
> > > > space,
> > > > > > and that will use it on addresses registered to a PCI host
> > bridge.
> > > > >
> > > > > Ok so here you are talking about a platform that has got an I/O
> > range
> > > > > under the PCI host controller, right?
> > > > > And this I/O range cannot be directly memory mapped but needs
> > special
> > > > > redirections for the I/O tokens, right?
> > > > >
> > > > > In this scenario registering the I/O ranges with the forbidden
> > range
> > > > > implemented by the current patch would still allow to redirect
> > I/O
> > > > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > > > >
> > > > > So effectively the special PCI host controller
> > > > > 1) knows the physical range that needs special redirection
> > > > > 2) register such range
> > > > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > > > special accessors
> > > > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in
> > 3)
> > > > >
> > > > > So to be honest I think this patch can fit well both with
> > > > > special PCI controllers that need I/O tokens redirection and with
> > > > > special non-PCI controllers that need non-PCI I/O physical
> > > > > address redirection...
> > > > >
> > > > > Thanks (and sorry for the long reply but I didn't know how
> > > > > to make the explanation shorter :) )
> > > > >
> > > > > Gab
> > > > >
> > > > > >
> > > > > > If we separate the two steps:
> > > > > >
> > > > > > a) assign a range of logical I/O port numbers to a bus
> > > > > > b) register a set of helpers for redirecting logical I/O
> > > > > > port to a helper function
> > > > > >
> > > > > > then I think the code will get cleaner and more flexible.
> > > > > > It should actually then be able to replace the powerpc
> > > > > > specific implementation.
> > > > > >
> > > > > > Arnd
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* [PATCH] f2fs: fix to account total free nid correctly
From: Chao Yu @ 2016-11-14 11:24 UTC (permalink / raw)
To: jaegeuk; +Cc: linux-f2fs-devel, linux-kernel, chao, Chao Yu
Thread A Thread B Thread C
- f2fs_create
- f2fs_new_inode
- f2fs_lock_op
- alloc_nid
alloc last nid
- f2fs_unlock_op
- f2fs_create
- f2fs_new_inode
- f2fs_lock_op
- alloc_nid
as node count still not
be increased, we will
loop in alloc_nid
- f2fs_write_node_pages
- f2fs_balance_fs_bg
- f2fs_sync_fs
- write_checkpoint
- block_operations
- f2fs_lock_all
- f2fs_lock_op
While creating new inode, we do not allocate and account nid atomically,
so that when there is almost no free nids left, we may encounter deadloop
like above stack.
In order to avoid that, add nm_i::free_nid_cnt for accounting free nids
and do nid allocation atomically during node creation.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
fs/f2fs/f2fs.h | 1 +
fs/f2fs/node.c | 19 +++++++++++++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 6de1fbf..9de6f20 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -551,6 +551,7 @@ struct f2fs_nm_info {
struct radix_tree_root free_nid_root;/* root of the free_nid cache */
struct list_head nid_list[MAX_NID_LIST];/* lists for free nids */
unsigned int nid_cnt[MAX_NID_LIST]; /* the number of free node id */
+ unsigned int free_nid_cnt; /* the number of total free nid */
spinlock_t nid_list_lock; /* protect nid lists ops */
struct mutex build_lock; /* lock for build free nids */
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index d58438f..e412d0e 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1885,11 +1885,13 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid)
return false;
}
#endif
- if (unlikely(sbi->total_valid_node_count + 1 > nm_i->available_nids))
- return false;
-
spin_lock(&nm_i->nid_list_lock);
+ if (unlikely(nm_i->free_nid_cnt == 0)) {
+ spin_unlock(&nm_i->nid_list_lock);
+ return false;
+ }
+
/* We should not use stale free nids created by build_free_nids */
if (nm_i->nid_cnt[FREE_NID_LIST] && !on_build_free_nids(nm_i)) {
f2fs_bug_on(sbi, list_empty(&nm_i->nid_list[FREE_NID_LIST]));
@@ -1900,6 +1902,7 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid)
__remove_nid_from_list(sbi, i, FREE_NID_LIST, true);
i->state = NID_ALLOC;
__insert_nid_to_list(sbi, i, ALLOC_NID_LIST, false);
+ nm_i->free_nid_cnt--;
spin_unlock(&nm_i->nid_list_lock);
return true;
}
@@ -1951,6 +1954,9 @@ void alloc_nid_failed(struct f2fs_sb_info *sbi, nid_t nid)
i->state = NID_NEW;
__insert_nid_to_list(sbi, i, FREE_NID_LIST, false);
}
+
+ nm_i->free_nid_cnt++;
+
spin_unlock(&nm_i->nid_list_lock);
if (need_free)
@@ -2222,8 +2228,12 @@ static void __flush_nat_entry_set(struct f2fs_sb_info *sbi,
raw_nat_from_node_info(raw_ne, &ne->ni);
nat_reset_flag(ne);
__clear_nat_cache_dirty(NM_I(sbi), ne);
- if (nat_get_blkaddr(ne) == NULL_ADDR)
+ if (nat_get_blkaddr(ne) == NULL_ADDR) {
add_free_nid(sbi, nid, false);
+ spin_lock(&NM_I(sbi)->nid_list_lock);
+ NM_I(sbi)->free_nid_cnt++;
+ spin_unlock(&NM_I(sbi)->nid_list_lock);
+ }
}
if (to_journal)
@@ -2302,6 +2312,7 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
nm_i->nid_cnt[FREE_NID_LIST] = 0;
nm_i->nid_cnt[ALLOC_NID_LIST] = 0;
nm_i->nat_cnt = 0;
+ nm_i->free_nid_cnt = nm_i->available_nids - sbi->total_valid_node_count;
nm_i->ram_thresh = DEF_RAM_THRESHOLD;
nm_i->ra_nid_pages = DEF_RA_NID_PAGES;
nm_i->dirty_nats_ratio = DEF_DIRTY_NAT_RATIO_THRESHOLD;
--
2.8.2.311.gee88674
^ permalink raw reply related
* [U-Boot] [PATCH] Do not force master mode on unaffected PHY's
From: Hans de Goede @ 2016-11-14 11:26 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161108163859.14760-1-oliver@schinagl.nl>
Hi,
On 08-11-16 17:38, Olliver Schinagl wrote:
> The current implementation to force the PHY into master mode is to have a
> define which affects all realtek PHY's. This is not needed as the problem
> only exists in the RTL8211C chips. Let us thus turn this into a quirk flag
> instead.
Series looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
^ permalink raw reply
* [PATCH] f2fs: fix to account total free nid correctly
From: Chao Yu @ 2016-11-14 11:24 UTC (permalink / raw)
To: jaegeuk; +Cc: chao, linux-kernel, linux-f2fs-devel
Thread A Thread B Thread C
- f2fs_create
- f2fs_new_inode
- f2fs_lock_op
- alloc_nid
alloc last nid
- f2fs_unlock_op
- f2fs_create
- f2fs_new_inode
- f2fs_lock_op
- alloc_nid
as node count still not
be increased, we will
loop in alloc_nid
- f2fs_write_node_pages
- f2fs_balance_fs_bg
- f2fs_sync_fs
- write_checkpoint
- block_operations
- f2fs_lock_all
- f2fs_lock_op
While creating new inode, we do not allocate and account nid atomically,
so that when there is almost no free nids left, we may encounter deadloop
like above stack.
In order to avoid that, add nm_i::free_nid_cnt for accounting free nids
and do nid allocation atomically during node creation.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
---
fs/f2fs/f2fs.h | 1 +
fs/f2fs/node.c | 19 +++++++++++++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 6de1fbf..9de6f20 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -551,6 +551,7 @@ struct f2fs_nm_info {
struct radix_tree_root free_nid_root;/* root of the free_nid cache */
struct list_head nid_list[MAX_NID_LIST];/* lists for free nids */
unsigned int nid_cnt[MAX_NID_LIST]; /* the number of free node id */
+ unsigned int free_nid_cnt; /* the number of total free nid */
spinlock_t nid_list_lock; /* protect nid lists ops */
struct mutex build_lock; /* lock for build free nids */
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index d58438f..e412d0e 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1885,11 +1885,13 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid)
return false;
}
#endif
- if (unlikely(sbi->total_valid_node_count + 1 > nm_i->available_nids))
- return false;
-
spin_lock(&nm_i->nid_list_lock);
+ if (unlikely(nm_i->free_nid_cnt == 0)) {
+ spin_unlock(&nm_i->nid_list_lock);
+ return false;
+ }
+
/* We should not use stale free nids created by build_free_nids */
if (nm_i->nid_cnt[FREE_NID_LIST] && !on_build_free_nids(nm_i)) {
f2fs_bug_on(sbi, list_empty(&nm_i->nid_list[FREE_NID_LIST]));
@@ -1900,6 +1902,7 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid)
__remove_nid_from_list(sbi, i, FREE_NID_LIST, true);
i->state = NID_ALLOC;
__insert_nid_to_list(sbi, i, ALLOC_NID_LIST, false);
+ nm_i->free_nid_cnt--;
spin_unlock(&nm_i->nid_list_lock);
return true;
}
@@ -1951,6 +1954,9 @@ void alloc_nid_failed(struct f2fs_sb_info *sbi, nid_t nid)
i->state = NID_NEW;
__insert_nid_to_list(sbi, i, FREE_NID_LIST, false);
}
+
+ nm_i->free_nid_cnt++;
+
spin_unlock(&nm_i->nid_list_lock);
if (need_free)
@@ -2222,8 +2228,12 @@ static void __flush_nat_entry_set(struct f2fs_sb_info *sbi,
raw_nat_from_node_info(raw_ne, &ne->ni);
nat_reset_flag(ne);
__clear_nat_cache_dirty(NM_I(sbi), ne);
- if (nat_get_blkaddr(ne) == NULL_ADDR)
+ if (nat_get_blkaddr(ne) == NULL_ADDR) {
add_free_nid(sbi, nid, false);
+ spin_lock(&NM_I(sbi)->nid_list_lock);
+ NM_I(sbi)->free_nid_cnt++;
+ spin_unlock(&NM_I(sbi)->nid_list_lock);
+ }
}
if (to_journal)
@@ -2302,6 +2312,7 @@ static int init_node_manager(struct f2fs_sb_info *sbi)
nm_i->nid_cnt[FREE_NID_LIST] = 0;
nm_i->nid_cnt[ALLOC_NID_LIST] = 0;
nm_i->nat_cnt = 0;
+ nm_i->free_nid_cnt = nm_i->available_nids - sbi->total_valid_node_count;
nm_i->ram_thresh = DEF_RAM_THRESHOLD;
nm_i->ra_nid_pages = DEF_RA_NID_PAGES;
nm_i->dirty_nats_ratio = DEF_DIRTY_NAT_RATIO_THRESHOLD;
--
2.8.2.311.gee88674
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
^ permalink raw reply related
* Re: [PATCH 2/2] mmc: tmio: remove SDIO from TODO list
From: Simon Horman @ 2016-11-14 11:25 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-mmc, linux-renesas-soc
In-Reply-To: <20161113142912.4041-3-wsa+renesas@sang-engineering.com>
On Sun, Nov 13, 2016 at 03:29:12PM +0100, Wolfram Sang wrote:
> We surely have SDIO support by now :)
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* Re: [PATCH v5 0/3] Add clockevet for timer-nps driver to NPS400 SoC
From: Daniel Lezcano @ 2016-11-14 11:25 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR0501MB251893C085505B65DFFF7BFCAABC0@DB6PR0501MB2518.eurprd05.prod.outlook.com>
On Mon, Nov 14, 2016 at 09:35:59AM +0000, Noam Camus wrote:
> >From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
> >Sent: Monday, November 14, 2016 10:28 AM
>
> >Noam,
>
> >I know it is patch 0/3, but each time you send a change there are new typos.
>
> >Sending new versions as fast as possible without double checking the changes won't make them merged sooner.
>
> >Nobody is perfect but clearly you don't read your patch before sending and that does not make me confident about the code changes.
>
> >In the future, take some minutes to double-check and re-read your changes.
>
> Thank you Daniel,
> I will do an extra check next time.
Triple check then because there are still typos in v6.
^ permalink raw reply
* Re: [PATCH v5 0/3] Add clockevet for timer-nps driver to NPS400 SoC
From: Daniel Lezcano @ 2016-11-14 11:25 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <DB6PR0501MB251893C085505B65DFFF7BFCAABC0-wTfl6qNNZ1PL+HUNrKNnF8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Mon, Nov 14, 2016 at 09:35:59AM +0000, Noam Camus wrote:
> >From: Daniel Lezcano [mailto:daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
> >Sent: Monday, November 14, 2016 10:28 AM
>
> >Noam,
>
> >I know it is patch 0/3, but each time you send a change there are new typos.
>
> >Sending new versions as fast as possible without double checking the changes won't make them merged sooner.
>
> >Nobody is perfect but clearly you don't read your patch before sending and that does not make me confident about the code changes.
>
> >In the future, take some minutes to double-check and re-read your changes.
>
> Thank you Daniel,
> I will do an extra check next time.
Triple check then because there are still typos in v6.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [ovmf baseline-only test] 68033: all pass
From: Platform Team regression test user @ 2016-11-14 11:25 UTC (permalink / raw)
To: xen-devel, osstest-admin
This run is configured for baseline tests only.
flight 68033 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68033/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8677a56af68ea7fc93938c710be2ec53752ae961
baseline version:
ovmf ffd6b0b1b65e620816fb16fe551f92309f4b7269
Last test of basis 68029 2016-11-13 05:48:23 Z 1 days
Testing same since 68033 2016-11-14 09:16:38 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Jeff Fan <jeff.fan@intel.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Push not applicable.
------------------------------------------------------------
commit 8677a56af68ea7fc93938c710be2ec53752ae961
Author: Jeff Fan <jeff.fan@intel.com>
Date: Fri Nov 11 19:51:36 2016 +0800
UefiCpuPkg/DxeMpLib: Place APs to suitable state on Legacy OS boot
Currently, DxeMpLib only places APs into specified c-state in Exit Boot Service
callback function for UEFI OS boot. We need to put APs into specified c-state
for legacy OS boot also.
https://bugzilla.tianocore.org/show_bug.cgi?id=210
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
commit 86af2eb8b4ec03e59c8c26cf7d51d294a7f905e7
Author: Jeff Fan <jeff.fan@intel.com>
Date: Fri Nov 11 19:48:09 2016 +0800
UefiCpuPkg/DxeMpLib: Rename MpInitExitBootServicesCallback()
Rename MpInitExitBootServicesCallback() to MpInitChangeApLoopCallback() because
it will not only be invoked on Exit Boot Service Event, but also will be invoked
on Legacy Ready To Boot Event.
https://bugzilla.tianocore.org/show_bug.cgi?id=210
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 1/2] mmc: tmio: fix wrong bitmask for SDIO irqs
From: Simon Horman @ 2016-11-14 11:24 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-mmc, linux-renesas-soc
In-Reply-To: <20161113142912.4041-2-wsa+renesas@sang-engineering.com>
On Sun, Nov 13, 2016 at 03:29:11PM +0100, Wolfram Sang wrote:
> Commit 7729c7a232a953 ("mmc: tmio: Provide separate interrupt handlers")
> refactored the sdio irq handler and wrongly used the mask for SD irqs,
> not for SDIO irqs. This doesn't really matter in practice because both
> values keep the only interrupt we are interested in. But still, this is
> wrong and wants to be fixed.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/mmc/host/tmio_mmc_pio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
> index dbc3cb14f3321b..2b04e6e87192c7 100644
> --- a/drivers/mmc/host/tmio_mmc_pio.c
> +++ b/drivers/mmc/host/tmio_mmc_pio.c
> @@ -741,7 +741,7 @@ static void tmio_mmc_sdio_irq(int irq, void *devid)
> return;
>
> status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
> - ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
> + ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdio_irq_mask;
>
> sdio_status = status & ~TMIO_SDIO_MASK_ALL;
> if (pdata->flags & TMIO_MMC_SDIO_STATUS_QUIRK)
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH] spi: spi-pxa2xx: Remove unused macro
From: Jarkko Nikula @ 2016-11-14 11:24 UTC (permalink / raw)
To: linux-spi-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Brown, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Jarkko Nikula
IS_DMA_ALIGNED() became unused by the commit 6356437e65c2
("spi: spi-pxa2xx: remove legacy PXA DMA bits").
Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
drivers/spi/spi-pxa2xx.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/spi/spi-pxa2xx.h b/drivers/spi/spi-pxa2xx.h
index ce31b8199bb3..2823a00a9405 100644
--- a/drivers/spi/spi-pxa2xx.h
+++ b/drivers/spi/spi-pxa2xx.h
@@ -109,7 +109,6 @@ static inline void pxa2xx_spi_write(const struct driver_data *drv_data,
#define DONE_STATE ((void *)2)
#define ERROR_STATE ((void *)-1)
-#define IS_DMA_ALIGNED(x) IS_ALIGNED((unsigned long)(x), DMA_ALIGNMENT)
#define DMA_ALIGNMENT 8
static inline int pxa25x_ssp_comp(struct driver_data *drv_data)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size
From: Chris Wilson @ 2016-11-14 11:23 UTC (permalink / raw)
To: Dan Carpenter; +Cc: intel-gfx
In-Reply-To: <20161114111455.GA13441@mwanda>
On Mon, Nov 14, 2016 at 02:14:56PM +0300, Dan Carpenter wrote:
> Hello Chris Wilson,
>
> The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max
> segment size" from Oct 11, 2016, leads to the following static
> checker warning:
>
> drivers/gpu/drm/i915/i915_gem.c:2357 i915_gem_object_get_pages_gtt()
> error: we previously assumed 'sg' could be null (see line 2341)
>
> drivers/gpu/drm/i915/i915_gem.c
> 2339 /* Check that the i965g/gm workaround works. */
> 2340 WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x00100000UL));
> 2341 }
> 2342 if (sg) /* loop terminated early; short sg table */
>
> We added a new check for NULL.
>
> 2343 sg_mark_end(sg);
> 2344
> 2345 /* Trim unused sg entries to avoid wasting memory. */
> 2346 i915_sg_trim(st);
> 2347
> 2348 ret = i915_gem_gtt_prepare_pages(obj, st);
> 2349 if (ret)
> 2350 goto err_pages;
>
> but we hit this goto
>
> 2351
> 2352 if (i915_gem_object_needs_bit17_swizzle(obj))
> 2353 i915_gem_object_do_bit_17_swizzle(obj, st);
> 2354
> 2355 return st;
> 2356
> 2357 err_pages:
> 2358 sg_mark_end(sg);
>
> Then don't check here. Also do we really need to sg_mark_end() twice?
We need the mark_end when escaping from the loop, but after the loop, sg
may be NULL.
Archaelogy, suggests commit e227330223a7 ("drm/i915: avoid leaking DMA
mappings") as the original culprit (i.e. the introduction of goto
err_pages after the loop).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-11-14 11:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven,
Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org, Dirk Behme,
linux-kernel@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdWavRFnYFmiL2jy3KWZnHG_F8qaxK29zHx6fsLmqXEwiA@mail.gmail.com>
On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
>
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff000044 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff000040 or 0xff000048 will result in a bus-level exception for a
> > missing register and just 0xff000044 is actually valid for access,
> > or is it just the only thing that is documented?
>
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.
Ok.
> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
>
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
>
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
>
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
>
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
>
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.
Ok, sounds good.
> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
>
> Looks like you forgot to finish your sentence?
Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.
Arnd
^ permalink raw reply
* Re: [PATCH v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Daniel Lezcano @ 2016-11-14 11:23 UTC (permalink / raw)
To: Noam Camus; +Cc: robh+dt, mark.rutland, tglx, devicetree, linux-kernel
In-Reply-To: <1479021872-14237-4-git-send-email-noamca@mellanox.com>
On Sun, Nov 13, 2016 at 09:24:32AM +0200, Noam Camus wrote:
> From: Noam Camus <noamca@mellanox.com>
>
> Till now we used clockevent from generic ARC driver.
> This was enough as long as we worked with simple multicore SoC.
> When we are working with multithread SoC each HW thread can be
> scheduled to receive timer interrupt using timer mask register.
> This patch will provide a way to control clock events per HW thread.
>
> The design idea is that for each core there is dedicated regirtser
s/regirtser/register/ (already spotted in v2).
> (TSI) serving all 16 HW threads.
> The register is a bitmask with one bit for each HW thread.
> When HW thread wants that next expiration of timer interrupt will
> hit it then the proper bit should be set in this dedicated register.
> When timer expires all HW threads within this core which their bit
> is set at the TSI register will be interrupted.
>
> Driver can be used from device tree by:
> compatible = "ezchip,nps400-timer0" <-- for clocksource
> compatible = "ezchip,nps400-timer1" <-- for clockevent
>
> Note that name convention for timer0/timer1 was taken from legacy
> ARC design. This design is our base before adding HW threads.
> For backward compatibility we keep "ezchip,nps400-timer" for clocksource
>
> Signed-off-by: Noam Camus <noamca@mellanox.com>
> ---
> .../bindings/timer/ezchip,nps400-timer.txt | 15 --
> .../bindings/timer/ezchip,nps400-timer0.txt | 17 ++
> .../bindings/timer/ezchip,nps400-timer1.txt | 15 ++
> drivers/clocksource/timer-nps.c | 213 ++++++++++++++++++++
> 4 files changed, 245 insertions(+), 15 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> deleted file mode 100644
> index c8c03d7..0000000
> --- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -NPS Network Processor
> -
> -Required properties:
> -
> -- compatible : should be "ezchip,nps400-timer"
> -
> -Clocks required for compatible = "ezchip,nps400-timer":
> -- clocks : Must contain a single entry describing the clock input
> -
> -Example:
> -
> -timer {
> - compatible = "ezchip,nps400-timer";
> - clocks = <&sysclk>;
> -};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> new file mode 100644
> index 0000000..e3cfce8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> @@ -0,0 +1,17 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer0"
> +
> +Clocks required for compatible = "ezchip,nps400-timer0":
> +- interrupts : The interrupt of the first timer
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer0";
> + interrupts = <3>;
> + clocks = <&sysclk>;
> +};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> new file mode 100644
> index 0000000..c0ab419
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> @@ -0,0 +1,15 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer1"
> +
> +Clocks required for compatible = "ezchip,nps400-timer1":
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer1";
> + clocks = <&sysclk>;
> +};
> diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
> index eeef9e9..ed4bce4 100644
> --- a/drivers/clocksource/timer-nps.c
> +++ b/drivers/clocksource/timer-nps.c
> @@ -109,3 +109,216 @@ static int __init nps_setup_clocksource(struct device_node *node)
>
> CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
> nps_setup_clocksource);
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
> + nps_setup_clocksource);
> +
> +#ifdef CONFIG_EZNPS_MTM_EXT
> +#include <soc/nps/mtm.h>
> +
> +/* Timer related Aux registers */
> +#define NPS_REG_TIMER0_TSI 0xFFFFF850
> +#define NPS_REG_TIMER0_LIMIT 0x23
> +#define NPS_REG_TIMER0_CTRL 0x22
> +#define NPS_REG_TIMER0_CNT 0x21
> +
> +/*
> + * Interrupt Enabled (IE) - re-arm the timer
> + * Not Halted (NH) - is cleared when working with JTAG (for debug)
> + */
> +#define TIMER0_CTRL_IE BIT(0)
> +#define TIMER0_CTRL_NH BIT(1)
> +
> +static unsigned long nps_timer0_freq;
> +static unsigned long nps_timer0_irq;
> +
> +/*
> + * Arm the timer to interrupt after @cycles
> + */
> +static void nps_clkevent_timer_event_setup(unsigned int cycles)
> +{
> + write_aux_reg(NPS_REG_TIMER0_LIMIT, cycles);
> + write_aux_reg(NPS_REG_TIMER0_CNT, 0);
> +
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +}
> +
> +/*
> + * Clear from TSI the bit for this thread (if not in periodic mode)
> + * If still there are pending HW treads set next timer event
s/treads/threads/
> + */
> +static void nps_clkevent_rm_thread(bool remove_thread)
> +{
> + unsigned int cflags;
> + unsigned int enabled_threads = 0;
> + int thread;
> +
> + hw_schd_save(&cflags);
I'm not used with hardware scheduling. Can you explain why this is needed
here ? What window race we want to close ?
> +
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> +
> + /* remove thread from TSI1 */
> + if (remove_thread) {
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads &= ~(1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> + }
> +
> + /* Re-arm the timer if needed */
> + if (!enabled_threads)
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_NH);
> + else
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
> +
> +static void nps_clkevent_add_thread(bool set_event)
> +{
> + int thread;
> + unsigned int cflags, enabled_threads;
> +
> + hw_schd_save(&cflags);
> +
> + /* add thread to TSI1 */
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> + enabled_threads |= (1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> +
> + /* set next timer event */
> + if (set_event)
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
Not sure the boolean parameters for *_rm_thread and *_add_thread helps
to clarify the code. Depending on the race window with hw_schd_save/restore
We should be able to simplify it.
> +static int nps_clkevent_set_next_event(unsigned long delta,
> + struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(true);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +/*
> + * Whenever anyone tries to change modes, we just mask interrupts
> + * and wait for the next event to get set.
> + */
> +static int nps_clkevent_timer_shutdown(struct clock_event_device *dev)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> +
> + return 0;
> +}
> +
> +/*
> + * For each HW thread set its relevant bit at the TSI register
> + * To arm the timer only thread 0 is needed since it is shared
> + * by all HW threads within same core.
> + */
> +static int nps_clkevent_set_periodic(struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(false);
> + if (read_aux_reg(CTOP_AUX_THREAD_ID) == 0)
> + nps_clkevent_timer_event_setup(nps_timer0_freq / HZ);
> +
> + return 0;
> +}
> +
> +static int nps_clkevent_set_oneshot(struct clock_event_device *dev)
> +{
> + nps_clkevent_rm_thread(true);
> + nps_clkevent_timer_shutdown(dev);
> +
> + return 0;
> +}
> +
> +static DEFINE_PER_CPU(struct clock_event_device, nps_clockevent_device) = {
> + .name = "NPS Timer0",
> + .features = CLOCK_EVT_FEAT_ONESHOT |
> + CLOCK_EVT_FEAT_PERIODIC,
> + .rating = 300,
> + .set_next_event = nps_clkevent_set_next_event,
> + .set_state_periodic = nps_clkevent_set_periodic,
> + .set_state_oneshot = nps_clkevent_set_oneshot,
> + .set_state_oneshot_stopped = nps_clkevent_timer_shutdown,
> + .set_state_shutdown = nps_clkevent_timer_shutdown,
Doesn't set_state_shutdown and set_state_oneshot_stopped need to remove
the HW thread from the TSI ?
> + .tick_resume = nps_clkevent_timer_shutdown,
> +};
> +
> +static irqreturn_t timer_irq_handler(int irq, void *dev_id)
> +{
> + struct clock_event_device *evt = dev_id;
> + int irq_reenable = clockevent_state_periodic(evt);
> +
> + /* Remove HW thread from TSI only if NOT in periodic state */
> + nps_clkevent_rm_thread(!irq_reenable);
> +
> + evt->event_handler(evt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int nps_timer_starting_cpu(unsigned int cpu)
> +{
> + struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
> +
> + evt->cpumask = cpumask_of(smp_processor_id());
> +
> + clockevents_config_and_register(evt, nps_timer0_freq, 0, ULONG_MAX);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +static int nps_timer_dying_cpu(unsigned int cpu)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> + return 0;
> +}
> +
> +static int __init nps_setup_clockevent(struct device_node *node)
> +{
> + struct clk *clk;
> + int ret;
> +
> + nps_timer0_irq = irq_of_parse_and_map(node, 0);
> + if (nps_timer0_irq <= 0) {
> + pr_err("clockevent: missing irq");
> + return -EINVAL;
> + }
> +
> + ret = nps_get_timer_clk(node, &nps_timer0_freq, &clk);
> + if (ret)
> + return ret;
> +
> + /* Needs apriori irq_set_percpu_devid() done in intc map function */
> + ret = request_percpu_irq(nps_timer0_irq, timer_irq_handler,
> + "Timer0 (per-cpu-tick)",
> + &nps_clockevent_device);
> + if (ret) {
> + pr_err("Couldn't request irq\n");
> + clk_disable_unprepare(clk);
> + return ret;
> + }
> +
> + ret = cpuhp_setup_state(CPUHP_AP_ARC_TIMER_STARTING,
> + "clockevents/nps:starting",
> + nps_timer_starting_cpu,
> + nps_timer_dying_cpu);
> + if (ret) {
> + pr_err("Failed to setup hotplug state");
> + clk_disable_unprepare(clk);
> + free_percpu_irq(nps_timer0_irq, &nps_clockevent_device);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
> + nps_setup_clockevent);
> +#endif /* CONFIG_EZNPS_MTM_EXT */
> --
> 1.7.1
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Daniel Lezcano @ 2016-11-14 11:23 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479021872-14237-4-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Sun, Nov 13, 2016 at 09:24:32AM +0200, Noam Camus wrote:
> From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Till now we used clockevent from generic ARC driver.
> This was enough as long as we worked with simple multicore SoC.
> When we are working with multithread SoC each HW thread can be
> scheduled to receive timer interrupt using timer mask register.
> This patch will provide a way to control clock events per HW thread.
>
> The design idea is that for each core there is dedicated regirtser
s/regirtser/register/ (already spotted in v2).
> (TSI) serving all 16 HW threads.
> The register is a bitmask with one bit for each HW thread.
> When HW thread wants that next expiration of timer interrupt will
> hit it then the proper bit should be set in this dedicated register.
> When timer expires all HW threads within this core which their bit
> is set at the TSI register will be interrupted.
>
> Driver can be used from device tree by:
> compatible = "ezchip,nps400-timer0" <-- for clocksource
> compatible = "ezchip,nps400-timer1" <-- for clockevent
>
> Note that name convention for timer0/timer1 was taken from legacy
> ARC design. This design is our base before adding HW threads.
> For backward compatibility we keep "ezchip,nps400-timer" for clocksource
>
> Signed-off-by: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/timer/ezchip,nps400-timer.txt | 15 --
> .../bindings/timer/ezchip,nps400-timer0.txt | 17 ++
> .../bindings/timer/ezchip,nps400-timer1.txt | 15 ++
> drivers/clocksource/timer-nps.c | 213 ++++++++++++++++++++
> 4 files changed, 245 insertions(+), 15 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> deleted file mode 100644
> index c8c03d7..0000000
> --- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -NPS Network Processor
> -
> -Required properties:
> -
> -- compatible : should be "ezchip,nps400-timer"
> -
> -Clocks required for compatible = "ezchip,nps400-timer":
> -- clocks : Must contain a single entry describing the clock input
> -
> -Example:
> -
> -timer {
> - compatible = "ezchip,nps400-timer";
> - clocks = <&sysclk>;
> -};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> new file mode 100644
> index 0000000..e3cfce8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> @@ -0,0 +1,17 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer0"
> +
> +Clocks required for compatible = "ezchip,nps400-timer0":
> +- interrupts : The interrupt of the first timer
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer0";
> + interrupts = <3>;
> + clocks = <&sysclk>;
> +};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> new file mode 100644
> index 0000000..c0ab419
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> @@ -0,0 +1,15 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer1"
> +
> +Clocks required for compatible = "ezchip,nps400-timer1":
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer1";
> + clocks = <&sysclk>;
> +};
> diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
> index eeef9e9..ed4bce4 100644
> --- a/drivers/clocksource/timer-nps.c
> +++ b/drivers/clocksource/timer-nps.c
> @@ -109,3 +109,216 @@ static int __init nps_setup_clocksource(struct device_node *node)
>
> CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
> nps_setup_clocksource);
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
> + nps_setup_clocksource);
> +
> +#ifdef CONFIG_EZNPS_MTM_EXT
> +#include <soc/nps/mtm.h>
> +
> +/* Timer related Aux registers */
> +#define NPS_REG_TIMER0_TSI 0xFFFFF850
> +#define NPS_REG_TIMER0_LIMIT 0x23
> +#define NPS_REG_TIMER0_CTRL 0x22
> +#define NPS_REG_TIMER0_CNT 0x21
> +
> +/*
> + * Interrupt Enabled (IE) - re-arm the timer
> + * Not Halted (NH) - is cleared when working with JTAG (for debug)
> + */
> +#define TIMER0_CTRL_IE BIT(0)
> +#define TIMER0_CTRL_NH BIT(1)
> +
> +static unsigned long nps_timer0_freq;
> +static unsigned long nps_timer0_irq;
> +
> +/*
> + * Arm the timer to interrupt after @cycles
> + */
> +static void nps_clkevent_timer_event_setup(unsigned int cycles)
> +{
> + write_aux_reg(NPS_REG_TIMER0_LIMIT, cycles);
> + write_aux_reg(NPS_REG_TIMER0_CNT, 0);
> +
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +}
> +
> +/*
> + * Clear from TSI the bit for this thread (if not in periodic mode)
> + * If still there are pending HW treads set next timer event
s/treads/threads/
> + */
> +static void nps_clkevent_rm_thread(bool remove_thread)
> +{
> + unsigned int cflags;
> + unsigned int enabled_threads = 0;
> + int thread;
> +
> + hw_schd_save(&cflags);
I'm not used with hardware scheduling. Can you explain why this is needed
here ? What window race we want to close ?
> +
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> +
> + /* remove thread from TSI1 */
> + if (remove_thread) {
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads &= ~(1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> + }
> +
> + /* Re-arm the timer if needed */
> + if (!enabled_threads)
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_NH);
> + else
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
> +
> +static void nps_clkevent_add_thread(bool set_event)
> +{
> + int thread;
> + unsigned int cflags, enabled_threads;
> +
> + hw_schd_save(&cflags);
> +
> + /* add thread to TSI1 */
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> + enabled_threads |= (1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> +
> + /* set next timer event */
> + if (set_event)
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
Not sure the boolean parameters for *_rm_thread and *_add_thread helps
to clarify the code. Depending on the race window with hw_schd_save/restore
We should be able to simplify it.
> +static int nps_clkevent_set_next_event(unsigned long delta,
> + struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(true);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +/*
> + * Whenever anyone tries to change modes, we just mask interrupts
> + * and wait for the next event to get set.
> + */
> +static int nps_clkevent_timer_shutdown(struct clock_event_device *dev)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> +
> + return 0;
> +}
> +
> +/*
> + * For each HW thread set its relevant bit at the TSI register
> + * To arm the timer only thread 0 is needed since it is shared
> + * by all HW threads within same core.
> + */
> +static int nps_clkevent_set_periodic(struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(false);
> + if (read_aux_reg(CTOP_AUX_THREAD_ID) == 0)
> + nps_clkevent_timer_event_setup(nps_timer0_freq / HZ);
> +
> + return 0;
> +}
> +
> +static int nps_clkevent_set_oneshot(struct clock_event_device *dev)
> +{
> + nps_clkevent_rm_thread(true);
> + nps_clkevent_timer_shutdown(dev);
> +
> + return 0;
> +}
> +
> +static DEFINE_PER_CPU(struct clock_event_device, nps_clockevent_device) = {
> + .name = "NPS Timer0",
> + .features = CLOCK_EVT_FEAT_ONESHOT |
> + CLOCK_EVT_FEAT_PERIODIC,
> + .rating = 300,
> + .set_next_event = nps_clkevent_set_next_event,
> + .set_state_periodic = nps_clkevent_set_periodic,
> + .set_state_oneshot = nps_clkevent_set_oneshot,
> + .set_state_oneshot_stopped = nps_clkevent_timer_shutdown,
> + .set_state_shutdown = nps_clkevent_timer_shutdown,
Doesn't set_state_shutdown and set_state_oneshot_stopped need to remove
the HW thread from the TSI ?
> + .tick_resume = nps_clkevent_timer_shutdown,
> +};
> +
> +static irqreturn_t timer_irq_handler(int irq, void *dev_id)
> +{
> + struct clock_event_device *evt = dev_id;
> + int irq_reenable = clockevent_state_periodic(evt);
> +
> + /* Remove HW thread from TSI only if NOT in periodic state */
> + nps_clkevent_rm_thread(!irq_reenable);
> +
> + evt->event_handler(evt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int nps_timer_starting_cpu(unsigned int cpu)
> +{
> + struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
> +
> + evt->cpumask = cpumask_of(smp_processor_id());
> +
> + clockevents_config_and_register(evt, nps_timer0_freq, 0, ULONG_MAX);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +static int nps_timer_dying_cpu(unsigned int cpu)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> + return 0;
> +}
> +
> +static int __init nps_setup_clockevent(struct device_node *node)
> +{
> + struct clk *clk;
> + int ret;
> +
> + nps_timer0_irq = irq_of_parse_and_map(node, 0);
> + if (nps_timer0_irq <= 0) {
> + pr_err("clockevent: missing irq");
> + return -EINVAL;
> + }
> +
> + ret = nps_get_timer_clk(node, &nps_timer0_freq, &clk);
> + if (ret)
> + return ret;
> +
> + /* Needs apriori irq_set_percpu_devid() done in intc map function */
> + ret = request_percpu_irq(nps_timer0_irq, timer_irq_handler,
> + "Timer0 (per-cpu-tick)",
> + &nps_clockevent_device);
> + if (ret) {
> + pr_err("Couldn't request irq\n");
> + clk_disable_unprepare(clk);
> + return ret;
> + }
> +
> + ret = cpuhp_setup_state(CPUHP_AP_ARC_TIMER_STARTING,
> + "clockevents/nps:starting",
> + nps_timer_starting_cpu,
> + nps_timer_dying_cpu);
> + if (ret) {
> + pr_err("Failed to setup hotplug state");
> + clk_disable_unprepare(clk);
> + free_percpu_irq(nps_timer0_irq, &nps_clockevent_device);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
> + nps_setup_clockevent);
> +#endif /* CONFIG_EZNPS_MTM_EXT */
> --
> 1.7.1
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Laurent Pinchart @ 2016-11-14 11:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
daniel-/w4YWyX8dFk, robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <ac8e0f72-fac2-45e5-0004-d6028ddeb221-l0cyMroinI0@public.gmane.org>
Hi Tomi,
On Monday 14 Nov 2016 13:16:49 Tomi Valkeinen wrote:
> On 14/11/16 13:10, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> >> On 11/03/16 19:46, Laurent Pinchart wrote:
> >>>> +Required properties:
> >>>>> + - compatible: "ti,tfp410"
> >>>
> >>> The device is an I2C slave, it should have a reg property. Given that
> >>> the chip can be used without being controlled through I2C, the reg
> >>> property should be optional. You should document this clearly, and
> >>> explain how the DT node can be instantiated as a child of an I2C
> >>> controller when the I2C interface is used, or in other parts of the
> >>> device tree otherwise.
> >>
> >> Shouldn't I have two different compatible strings if want to make both
> >> platform driver probe and i2c client probe to work?
> >
> > I don't think so, it's still the same chip.
> >
> >> Or can it be done with single compatible string? Would you know of an
> >> example of such a driver?
> >
> > You will need to register both a i2c_driver and a platform_driver in the
> > tfp410 driver. Both will advertise the same compatible string. As you'll
> > have two probe functions, it should be easy to handle the differences
> > between the
>
> If you have the same compatible string, won't both probes trigger? If
> so, how does, e.g., the platform driver know this is actually i2c case,
> and bail out? And if both probes don't trigger, why not? How does the
> device probing machinery know that this DT node is actually an i2c node,
> not a platform device node?
The driver for the bus on which the device is sitting is responsible for
instantiating a struct device corresponding to the bus type, and for binding
the corresponding bus drivers. This will be a struct i2c_client for I2C buses,
and a struct platform_device for platform buses. Only the corresponding driver
type will be probed.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-11-14 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWavRFnYFmiL2jy3KWZnHG_F8qaxK29zHx6fsLmqXEwiA@mail.gmail.com>
On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
>
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff000044 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff000040 or 0xff000048 will result in a bus-level exception for a
> > missing register and just 0xff000044 is actually valid for access,
> > or is it just the only thing that is documented?
>
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.
Ok.
> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
>
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
>
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
>
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
>
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
>
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.
Ok, sounds good.
> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
>
> Looks like you forgot to finish your sentence?
Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.
Arnd
^ permalink raw reply
* [meta-oe][PATCH] libeigen: set tarball name as ${BP}.tar.bz2
From: wenzong.fan @ 2016-11-14 11:22 UTC (permalink / raw)
To: openembedded-devel
From: Wenzong Fan <wenzong.fan@windriver.com>
Rename tarball name: 3.2.8.tar.bz2 -> libeigen-3.2.8.tar.bz2
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
---
meta-oe/recipes-support/libeigen/libeigen_3.2.8.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-support/libeigen/libeigen_3.2.8.bb b/meta-oe/recipes-support/libeigen/libeigen_3.2.8.bb
index 9e14ee1..dcca2e9 100644
--- a/meta-oe/recipes-support/libeigen/libeigen_3.2.8.bb
+++ b/meta-oe/recipes-support/libeigen/libeigen_3.2.8.bb
@@ -4,7 +4,7 @@ HOMEPAGE = "http://eigen.tuxfamily.org/"
LICENSE = "MPL-2.0"
LIC_FILES_CHKSUM = "file://COPYING.MPL2;md5=815ca599c9df247a0c7f619bab123dad"
-SRC_URI = "http://bitbucket.org/eigen/eigen/get/${PV}.tar.bz2 \
+SRC_URI = "http://bitbucket.org/eigen/eigen/get/${PV}.tar.bz2;downloadfilename=${BP}.tar.bz2 \
file://0001-CMakeLists.txt-install-FindEigen3.cmake-script.patch"
SRC_URI[md5sum] = "9e3bfaaab3db18253cfd87ea697b3ab1"
SRC_URI[sha256sum] = "722a63d672b70f39c271c5e2a4a43ba14d12015674331790414fcb167c357e55"
--
2.9.3
^ permalink raw reply related
* [meta-oe][PATCH] opencv: fix QA issue
From: wenzong.fan @ 2016-11-14 11:22 UTC (permalink / raw)
To: openembedded-devel
From: Wenzong Fan <wenzong.fan@windriver.com>
Replace '/lib' with '${baselib}' to fix QA issue:
ERROR: do_package_qa: QA Issue: non -staticdev package contains \
static .a library: opencv-apps path \
'.../opencv-apps/usr/share/OpenCV/3rdparty/lib64/libippicv.a' \
[staticdev]
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
---
meta-oe/recipes-support/opencv/opencv_3.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-support/opencv/opencv_3.1.bb b/meta-oe/recipes-support/opencv/opencv_3.1.bb
index 2136b07..72bf5b4 100644
--- a/meta-oe/recipes-support/opencv/opencv_3.1.bb
+++ b/meta-oe/recipes-support/opencv/opencv_3.1.bb
@@ -116,7 +116,7 @@ PACKAGES_DYNAMIC += "^libopencv-.*"
FILES_${PN} = ""
FILES_${PN}-apps = "${bindir}/* ${datadir}/OpenCV"
-FILES_${PN}-dev = "${includedir} ${libdir}/pkgconfig ${datadir}/OpenCV/*.cmake ${datadir}/OpenCV/3rdparty/lib/*.a"
+FILES_${PN}-dev = "${includedir} ${libdir}/pkgconfig ${datadir}/OpenCV/*.cmake ${datadir}/OpenCV/3rdparty/${baselib}/*.a"
FILES_${PN}-doc = "${datadir}/OpenCV/doc"
FILES_${PN}-java = "${datadir}/OpenCV/java"
FILES_${PN}-java-dbg = "${datadir}/OpenCV/java/.debug/"
--
2.9.3
^ permalink raw reply related
* [U-Boot] [PATCH 00/10] sunxi: Add basic PSCI support to enable SMP on the A80's first cluster
From: Chen-Yu Tsai @ 2016-11-14 11:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <75ca81dd-a7e7-d242-6e2f-6071ece507c4@redhat.com>
Hi,
On Wed, Nov 9, 2016 at 6:38 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 09-11-16 11:21, Chen-Yu Tsai wrote:
>>
>> Hi everyone,
>>
>> This series adds basic PSCI support for the A80 to enable SMP on the
>> first cluster. This at least allows people to use more than one core.
>> The term "basic" is used because the series does not add support for
>> multi-cluster cache and power management.
>>
>> The PSCI code is based on existing code for all the single cluster
>> SoCs, and the kernel patches for MCPM SMP I did some time ago.
>>
>> Unfortunately only SMP works at this time. The last patch does not
>> actually work. While the system is indeed booted non-secure, tested
>> by trying to write to secure SRAM and the results not sticking, reads
>> from the GIC CPU interface shows that it's still returning the secure
>> copy of registers, and since we use a secure monitor FIQ to do core
>> power down, the FIQ gets passed to the kernel. The patch is included
>> so people with in-depth ARM knowledge could probably help work out
>> what is wrong.
>
>
> Cools stuff, when I find some time I will review and merge
> patches 1-9 to sunxi-next.
>
> First a question though, do you see any chance that merging this might
> get in the way of enabling support for both clusters in the future?
>
> Since the interface between u-boot and the kernel here is well defined
> (and outside our control) I guess in the worst case, we would need to
> revert some bits of this series from u-boot if they turn out to be non
> suitable, right?
So I started digging through why CPU power off is sending FIQs to the
kernel. So it turns out that the GIC base address programmed in the
CPU's CBAR is incorrect, so the GIC is not blocking secure interrupts,
and when the interrupt returns the CPU seems to get switched to secure
mode.
After hard-coding in the correct address, the system no longer boots.
It hangs when it tries to bring up the second core. I'm not sure
what's going on though. Need to add some more trace code.
I might have opened a can of worms...
ChenYu
>
> Regards,
>
> Hans
>
>
>
>
>>
>>
>> Regards
>> ChenYu
>>
>> Chen-Yu Tsai (10):
>> ARM: PSCI: Set ARMV7_PSCI_NR_CPUS default to 8 for sun9i/A80
>> sunxi: Add CCI-400 and CPUCFG registers base address for sun9i/A80
>> sunxi: Add base address of secure SRAM B for sun9i/A80
>> sunxi: Use secure SRAM B for secure RAM for sun9i/A80
>> sunxi: Add PRCM register definition for sun9i/A80
>> sunxi: Add CPUCFG register definitions for sun9i/A80
>> sunxi: Add support for TZPC on sun9i/A80
>> sunxi: Add basic PSCI implementation for A80
>> sunxi: Enable PSCI on sun9i/A80
>> sunxi: Add PSCI core power off support for A80's first cluster
>>
>> arch/arm/cpu/armv7/Kconfig | 1 +
>> arch/arm/cpu/armv7/sunxi/Makefile | 5 +
>> arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 322
>> +++++++++++++++++++++++++
>> arch/arm/cpu/armv7/sunxi/tzpc.c | 6 +
>> arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 5 +
>> arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 51 ++++
>> arch/arm/include/asm/arch-sunxi/prcm_sun9i.h | 55 +++++
>> arch/arm/include/asm/arch-sunxi/tzpc.h | 4 +
>> arch/arm/mach-sunxi/board.c | 3 +-
>> board/sunxi/Kconfig | 4 +
>> include/configs/sun9i.h | 4 +
>> 11 files changed, 459 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
>> create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
>> create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h
>>
>
^ permalink raw reply
* [bug report] iwlwifi: mvm: use dev_coredumpsg()
From: Dan Carpenter @ 2016-11-14 11:20 UTC (permalink / raw)
To: aviya.erenfeld; +Cc: linux-wireless
Hello Aviya Erenfeld,
The patch 7e62a699aafb: "iwlwifi: mvm: use dev_coredumpsg()" from Sep
20, 2016, leads to the following static checker warning:
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c:821 iwl_mvm_fw_error_dump()
error: we previously assumed 'fw_error_dump->trans_ptr' could be null (see line 809)
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
805 dump_trans_data:
806 fw_error_dump->trans_ptr = iwl_trans_dump_data(mvm->trans,
807 mvm->fw_dump_trig);
808 fw_error_dump->op_mode_len = file_len;
809 if (fw_error_dump->trans_ptr)
810 file_len += fw_error_dump->trans_ptr->len;
We assume ->trans_ptr can be NULL.
811 dump_file->file_len = cpu_to_le32(file_len);
812
813 sg_dump_data = alloc_sgtable(file_len);
That probably means file_len is zero? (didn't look). That means
sg_dump_data is ZERO_SIZE_PTR (16).
814 if (sg_dump_data) {
815 sg_pcopy_from_buffer(sg_dump_data,
816 sg_nents(sg_dump_data),
817 fw_error_dump->op_mode_ptr,
818 fw_error_dump->op_mode_len, 0);
819 sg_pcopy_from_buffer(sg_dump_data,
820 sg_nents(sg_dump_data),
821 fw_error_dump->trans_ptr->data,
Leading to an oops.
822 fw_error_dump->trans_ptr->len,
823 fw_error_dump->op_mode_len);
824 dev_coredumpsg(mvm->trans->dev, sg_dump_data, file_len,
825 GFP_KERNEL);
826 }
827 vfree(fw_error_dump->op_mode_ptr);
828 vfree(fw_error_dump->trans_ptr);
829 kfree(fw_error_dump);
830
831 out:
832 iwl_mvm_free_fw_dump_desc(mvm);
833 mvm->fw_dump_trig = NULL;
834 clear_bit(IWL_MVM_STATUS_DUMPING_FW_LOG, &mvm->status);
835 }
regards,
dan carpenter
^ permalink raw reply
* [U-Boot] [PATCH 7/7] sunxi: Add support for the CHIP Pro
From: Hans de Goede @ 2016-11-14 11:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <be13289f14a55434600bfb4a859d9a28b3c49b5b.1478621974.git-series.maxime.ripard@free-electrons.com>
Hi,
On 08-11-16 17:21, Maxime Ripard wrote:
> The CHIP Pro is a SoM that features the GR8 SIP, an AXP209, a BT/WiFi chip
> and a 512MiB SLC NAND.
>
> This it's an SLC NAND, it doesn't suffer the same drawbacks than found on
> the MLC NANDs, and we can enable it right away.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch 3/3 needs a v3 before this can be merged, otherwise this
looks good to me:
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
> ---
> configs/CHIP_pro_defconfig | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+), 0 deletions(-)
> create mode 100644 configs/CHIP_pro_defconfig
>
> diff --git a/configs/CHIP_pro_defconfig b/configs/CHIP_pro_defconfig
> new file mode 100644
> index 000000000000..6008f44f485c
> --- /dev/null
> +++ b/configs/CHIP_pro_defconfig
> @@ -0,0 +1,27 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +CONFIG_SPL_I2C_SUPPORT=y
> +# CONFIG_SPL_MMC_SUPPORT is not set
> +CONFIG_MACH_SUN5I=y
> +CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y
> +# CONFIG_MMC is not set
> +CONFIG_USB0_VBUS_PIN="PB10"
> +CONFIG_DEFAULT_DEVICE_TREE="ntc-gr8-chip-pro"
> +CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,SYS_NAND_BLOCK_SIZE=0x40000,SYS_NAND_PAGE_SIZE=4096,SYS_NAND_OOBSIZE=256,ENV_IS_IN_NAND"
> +CONFIG_SPL=y
> +# CONFIG_CMD_IMLS is not set
> +CONFIG_CMD_DFU=y
> +CONFIG_CMD_USB_MASS_STORAGE=y
> +CONFIG_DFU_RAM=y
> +CONFIG_AXP_ALDO3_VOLT=3300
> +CONFIG_AXP_ALDO4_VOLT=3300
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_MUSB_GADGET=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_G_DNL_MANUFACTURER="Allwinner Technology"
> +CONFIG_G_DNL_VENDOR_NUM=0x1f3a
> +CONFIG_G_DNL_PRODUCT_NUM=0x1010
> +CONFIG_NAND_SUNXI=y
> +CONFIG_SPL_NAND_SUPPORT=y
> +CONFIG_MTD_UBI=y
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.