* Re: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
From: Arnd Bergmann @ 2014-02-27 19:48 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Jason Gunthorpe, Liviu Dudau, linux-pci, Bjorn Helgaas,
Catalin Marinas, Will Deacon, linaro-kernel,
devicetree@vger.kernel.org, LKML
In-Reply-To: <20140227193627.GA7773@obsidianresearch.com>
On Thursday 27 February 2014 12:36:27 Jason Gunthorpe wrote:
> On Thu, Feb 27, 2014 at 07:12:59PM +0000, Liviu Dudau wrote:
> > The outstanding issue is how to fix pci_address_to_pio() as it will not
> > for for range->cpu_addr > IO_SPACE_LIMIT (16MB in my case).
>
> The default actually looks fine to me, it is the correct behavior for
> systems that actually have a dedicated IO space (like x86) where the
> 'CPU' value for IO is the exact value used in the IO accessor
> instructions. In this case the IO_SPACE_LIMIT test is appropriate.
Right.
> It also looks correct for architectures that use the CPU MMIO address
> as the IO address directly (where IO_SPACE_LIMIT would be 4G)
Are you aware of any that still do? I thought we had stopped doing
that.
> Architectures that use the virtual IO window technique will always
> require a custom pci_address_to_pio implementation.
Hmm, at the moment we only call it from of_address_to_resource(),
which in turn does not get called on PCI devices, and does not
call pci_address_to_pio for 'simple' platform devices. The only
case I can think of where it actually matters is when we have
ISA devices in DT that use an I/O port address in the reg property,
and that case hopefully won't happen on ARM32 or ARM64.
> BTW, something that occured to me after reading the patches:
>
> For ARM64 you might want to think about doing away with the fixed
> virtual IO window like we see in ARM32. Just use the CPU MMIO address
> directly within the kernel, and implement a ioport_map to setup the MM
> on demand.
>
> I think the legacy reasons for having all those layers of translation
> are probably not applicable to ARM64, and it is much simpler without
> the extra translation step....
>
> Arnd, what do you think?
Either I don't like it or I misunderstand you ;-)
Most PCI drivers normally don't call ioport_map or pci_iomap, so
we can't just do it there. If you are thinking of calling ioport_map
for every PCI device that has an I/O BAR and storing the virtual
address in the pci_dev resource, I don't see what that gains us
in terms of complexity, and it will also break /dev/port.
Arnd
^ permalink raw reply
* [PATCH] checkpatch: fix spurious vendor compatible warnings
From: Florian Vaussard @ 2014-02-27 19:56 UTC (permalink / raw)
To: Andy Whitcroft, Joe Perches
Cc: Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Florian Vaussard
With a compatible string like
compatible = "foo";
checkpatch will currently try to find "foo" in vendor-prefixes.txt,
which is wrong since the vendor prefix is empty in this specific case.
Skip the vendor test if the compatible is not like
compatible = "vendor,something";
Signed-off-by: Florian Vaussard <florian.vaussard-p8DiymsW2f8@public.gmane.org>
---
scripts/checkpatch.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 464dcef..35ec185 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2058,6 +2058,7 @@ sub process {
my $vendor = $compat;
my $vendor_path = $dt_path . "vendor-prefixes.txt";
next if (! -f $vendor_path);
+ next if not $vendor =~ /^[a-zA-Z0-9]+\,.*/;
$vendor =~ s/^([a-zA-Z0-9]+)\,.*/$1/;
`grep -Eq "$vendor" $vendor_path`;
if ( $? >> 8 ) {
--
1.8.5.3
--
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 related
* Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
From: Loc Ho @ 2014-02-27 19:57 UTC (permalink / raw)
To: balbi
Cc: Kishon Vijay Abraham I, Tejun Heo, Olof Johansson, Arnd Bergmann,
linux-kernel, Linux SCSI List, linux-ide@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Don Dutile, Jon Masters, patches@apm.com
In-Reply-To: <20140227190102.GB4862@saruman.home>
Hi Balbi,
> On Thu, Feb 27, 2014 at 11:14:05AM -0700, Loc Ho wrote:
>> This patch adds function set_speed to the generic PHY framework operation
>> structure. This function can be called to instruct the PHY underlying layer
>> at specified lane to configure for specified speed in hertz.
>
> why ? looks like clk_set_rate() is your friend here. Can you be more
> descriptive of the use case ? When will this be used ?
>
The phy_set_speed is used to configure the operation speed of the PHY
at run-time. The clock interface in general is used to configure the
clock input to the IP. I don't believe they are the same thing. Maybe
it will be clear in my response to your second email
-Loc
^ permalink raw reply
* Re: [PATCH v12 3/4] PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
From: Loc Ho @ 2014-02-27 20:02 UTC (permalink / raw)
To: balbi
Cc: Kishon Vijay Abraham I, Tejun Heo, Olof Johansson, Arnd Bergmann,
linux-kernel, Linux SCSI List, linux-ide@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Don Dutile, Jon Masters, patches@apm.com, Tuan Phan,
Suman Tripathi
In-Reply-To: <20140227190259.GC4862@saruman.home>
Hi Balbi,
>> +/*
>> + * This function is used to configure the PHY to operation as either SATA Gen1
>> + * or Gen2 speed.
>> + */
>> +static void xgene_phy_sata_force_gen(struct xgene_phy_ctx *ctx,
>> + int lane, int gen)
>
> why do you need to *force* the generation ? Is this because of some
> silicon errata ? It almost seems like this should be done through link
> negotiation between both link partners.
You can call this as an errata or limitation of the underlying PHY IP.
As start, the PHY is configured with auto neg up to 6Gbps (or Gen3
speed). After link up, we will know whether it is Gen1 (1.5Gbps), Gen2
(3.0Gbps), or Gen3 (6.0Gbps). In order to ensure reliability, the PHY
needs to be configured at specified speed. For this reason and after
link up, the PHY is re-trained for the linked up speed.
-Loc
^ permalink raw reply
* [PATCH] of: add vendor prefix for SMSC
From: Florian Vaussard @ 2014-02-27 20:04 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Florian Vaussard
Add a vendor prefix for Standard Microsystems Corporation, now part of
Microchip.
Signed-off-by: Florian Vaussard <florian.vaussard-p8DiymsW2f8@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 40ce2df..7187c71 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -80,6 +80,7 @@ sil Silicon Image
silabs Silicon Laboratories
simtek
sirf SiRF Technology, Inc.
+smsc Standard Microsystems Corporation
snps Synopsys, Inc.
spansion Spansion Inc.
st STMicroelectronics
--
1.8.5.3
--
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 related
* Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
From: mark gross @ 2014-02-27 20:06 UTC (permalink / raw)
To: Stephen Warren
Cc: Gross, Mark, Linus Walleij, Alexandre Courbot, Grant Likely,
devicetree@vger.kernel.org, Chen-Yu Tsai, Heikki Krogerus,
Johannes Berg, David S. Miller, Rhyland Klein, linux-wireless,
netdev, linux-kernel, Arnd Bergmann, Westerberg, Mika
In-Reply-To: <530F7A4E.700@wwwdotorg.org>
On Thu, Feb 27, 2014 at 10:47:58AM -0700, Stephen Warren wrote:
> On 02/27/2014 10:38 AM, Gross, Mark wrote:
> > Please know that no one should not consider me an authority on ACPI at this
> > time. But, I have some comments / context / thoughts below.
> >
> > Also I apologize in advance for any email formatting issues caused by
> > replying to this via my work exchange account / outlook client. Folks can
> > use mgross@linux.intel.com to avoid outlook-isms from me in the future.
> >
> >> -----Original Message-----
> >> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> >> Sent: Tuesday, February 25, 2014 1:14 AM
> >> To: Stephen Warren; Alexandre Courbot; Grant Likely;
> >> devicetree@vger.kernel.org
> >> Cc: Chen-Yu Tsai; Heikki Krogerus; Johannes Berg; David S. Miller; Rhyland
> >> Klein; linux-wireless; netdev; linux-kernel; Arnd Bergmann; Gross, Mark
> >> Subject: Re: [PATCH 2/4] net: rfkill: gpio: remove gpio names
> >>
> >> On Fri, Feb 21, 2014 at 6:35 AM, Stephen Warren
> >> <swarren@wwwdotorg.org> wrote:
> >>> On 02/20/2014 06:55 PM, Chen-Yu Tsai wrote:
> >>
> >>>> That's correct. However using con_id to pass this results in
> >>>> different behavior across DT and ACPI. A better way is to export the
> >>>> labeling function so consumers can set meaningful labels themselves.
> >>>
> >>> But this code is the consumer of those GPIOs. IF the parameter to
> >>> devm_gpiod_get_index() isn't intended to be used, why does it exist?
> >>
> >> Kerneldoc says:
> >>
> >> /**
> >> * gpiod_get_index - obtain a GPIO from a multi-index GPIO function
> >> * @dev: GPIO consumer, can be NULL for system-global GPIOs
> >> * @con_id: function within the GPIO consumer
> >> * @idx: index of the GPIO to obtain in the consumer
> >> *
> >>
> >> Basically it is just exposing the fact that of_find_gpio() and
> >> acpi_find_gpio() both take a con_id as argument.
> >>
> >> If we drill into this, we find that it is used to conjure the arbitrary string
> >> before the gpios in the DT case, like:
> >>
> >> foo-gpios = <...>;
> >>
> >> As in tegra30-beaver.dts...
> >>
> >> sdhci@78000000 {
> >> status = "okay";
> >> cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
> >> wp-gpios = <&gpio TEGRA_GPIO(T, 3) GPIO_ACTIVE_HIGH>;
> >> power-gpios = <&gpio TEGRA_GPIO(D, 7) GPIO_ACTIVE_HIGH>;
> >> bus-width = <4>;
> >> };
> >>
> >> Instead of passing the GPIOs as index 0,1,2 they are named and I do admit
> >> this has a nice "things are under control" aspect to it.
> >
> > [Gross, Mark] FWIW I don't think this is as "under control" as you do. Those
> > names in the above sdhci example are derived from a specific SDHCI
> tegra spec
> > sheet or schematic. Those names likely come from the data sheet for
> > the controller.
>
> The names of the properties are fixed and defined by the DT binding for
> the Tegra SDHCI controller, or even the core SDHCI bindings. Hence, they
> will be the same in every DT file that uses that Tegra SDHCI compatible
> value (the compatible property isn't show above, because the above
> fragment is a board.dts file, and the compatible value gets inherited
> from the soc.dtsi file). There won't be any variation at all,
> irrespective of what signal names exist in a particular board schematic.
>
> If there were ever an (upstream?) ACPI "binding"(?) for the Tegra SDHCI
> controller, I would hope it would use the exact same names for the GPIO
> signals.
me to!
--mark
^ permalink raw reply
* Re: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
From: Jason Gunthorpe @ 2014-02-27 20:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Liviu Dudau, linux-pci, Bjorn Helgaas,
Catalin Marinas, Will Deacon, linaro-kernel,
devicetree@vger.kernel.org, LKML
In-Reply-To: <5379319.g8IPYmY2Zo@wuerfel>
On Thu, Feb 27, 2014 at 08:48:08PM +0100, Arnd Bergmann wrote:
> > It also looks correct for architectures that use the CPU MMIO address
> > as the IO address directly (where IO_SPACE_LIMIT would be 4G)
>
> Are you aware of any that still do? I thought we had stopped doing
> that.
I thought ia64 used to, but it has been a long time since I've touched
one...
> > Architectures that use the virtual IO window technique will always
> > require a custom pci_address_to_pio implementation.
>
> Hmm, at the moment we only call it from of_address_to_resource(),
> which in turn does not get called on PCI devices, and does not
> call pci_address_to_pio for 'simple' platform devices. The only
> case I can think of where it actually matters is when we have
> ISA devices in DT that use an I/O port address in the reg property,
> and that case hopefully won't happen on ARM32 or ARM64.
Sure, I ment, after Liviu's patch it will become required since he is
cleverly using it to figure out what the io mapping the bridge driver
setup before calling the helper.
> > I think the legacy reasons for having all those layers of translation
> > are probably not applicable to ARM64, and it is much simpler without
> > the extra translation step....
> >
> > Arnd, what do you think?
>
> Either I don't like it or I misunderstand you ;-)
>
> Most PCI drivers normally don't call ioport_map or pci_iomap, so
> we can't just do it there. If you are thinking of calling ioport_map
Okay, that was one of the 'legacy reasons'. Certainly lots of drivers
do call pci_iomap, but if you think legacy drivers that don't are
important to ARM64 then it makes sense to use the virtual IO window.
> for every PCI device that has an I/O BAR and storing the virtual
> address in the pci_dev resource, I don't see what that gains us
Mainly we get to drop the fancy dynamic allocation stuff for the fixed
virtual window, and it gives the option to have a 1:1 relationship
between CPU addresses and PCI BARs.
> in terms of complexity, and it will also break /dev/port.
Yes, /dev/port needs updating, it would need to iomap (arguably it
probably should be doing that already anyhow), and the hardwired limit
of 65536 needs to be replaced with the arch's IO limit, but those do
not seem to be fundemental problems with the UAPI??
Jason
^ permalink raw reply
* Re: [PATCH] checkpatch: fix spurious vendor compatible warnings
From: Joe Perches @ 2014-02-27 20:10 UTC (permalink / raw)
To: Florian Vaussard
Cc: Andy Whitcroft, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1393531019-25134-1-git-send-email-florian.vaussard-p8DiymsW2f8@public.gmane.org>
On Thu, 2014-02-27 at 20:56 +0100, Florian Vaussard wrote:
> With a compatible string like
>
> compatible = "foo";
>
> checkpatch will currently try to find "foo" in vendor-prefixes.txt,
> which is wrong since the vendor prefix is empty in this specific case.
>
> Skip the vendor test if the compatible is not like
>
> compatible = "vendor,something";
>
> Signed-off-by: Florian Vaussard <florian.vaussard-p8DiymsW2f8@public.gmane.org>
> ---
> scripts/checkpatch.pl | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 464dcef..35ec185 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2058,6 +2058,7 @@ sub process {
> my $vendor = $compat;
> my $vendor_path = $dt_path . "vendor-prefixes.txt";
> next if (! -f $vendor_path);
> + next if not $vendor =~ /^[a-zA-Z0-9]+\,.*/;
> $vendor =~ s/^([a-zA-Z0-9]+)\,.*/$1/;
> `grep -Eq "$vendor" $vendor_path`;
> if ( $? >> 8 ) {
Some vendor names have dashes.
I don't know if underscores are allowed.
$ grep -rP --include=*.[ch] -oh "compatible\s*=\s*\"[^,]+,\w" * | \
sed -r -e 's/\s//g' -e 's/,.$//' | sort | uniq -c | grep "[_-]"
1 compatible="active-semi
8 compatible="asahi-kasei
--
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 v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources.
From: Arnd Bergmann @ 2014-02-27 20:22 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: devicetree@vger.kernel.org, linaro-kernel, linux-pci, Liviu Dudau,
LKML, Will Deacon, Catalin Marinas, Bjorn Helgaas,
linux-arm-kernel
In-Reply-To: <20140227200729.GB7773@obsidianresearch.com>
On Thursday 27 February 2014 13:07:29 Jason Gunthorpe wrote:
> On Thu, Feb 27, 2014 at 08:48:08PM +0100, Arnd Bergmann wrote:
> > > It also looks correct for architectures that use the CPU MMIO address
> > > as the IO address directly (where IO_SPACE_LIMIT would be 4G)
> >
> > Are you aware of any that still do? I thought we had stopped doing
> > that.
>
> I thought ia64 used to, but it has been a long time since I've touched
> one...
They have a different way of doing it now, no idea how it looked in
the past:
#define IO_SPACE_LIMIT 0xffffffffffffffffUL
#define MAX_IO_SPACES_BITS 8
#define MAX_IO_SPACES (1UL << MAX_IO_SPACES_BITS)
#define IO_SPACE_BITS 24
#define IO_SPACE_SIZE (1UL << IO_SPACE_BITS)
#define IO_SPACE_NR(port) ((port) >> IO_SPACE_BITS)
#define IO_SPACE_BASE(space) ((space) << IO_SPACE_BITS)
#define IO_SPACE_PORT(port) ((port) & (IO_SPACE_SIZE - 1))
#define IO_SPACE_SPARSE_ENCODING(p) ((((p) >> 2) << 12) | ((p) & 0xfff))
So their port number is a logical token that contains the I/O space number
and a 16MB offset.
Apparently sparc64 uses physical memory addressing for I/O space, the
same way they do for memory space, and they just set IO_SPACE_LIMIT to
0xffffffffffffffffUL.
> > > Architectures that use the virtual IO window technique will always
> > > require a custom pci_address_to_pio implementation.
> >
> > Hmm, at the moment we only call it from of_address_to_resource(),
> > which in turn does not get called on PCI devices, and does not
> > call pci_address_to_pio for 'simple' platform devices. The only
> > case I can think of where it actually matters is when we have
> > ISA devices in DT that use an I/O port address in the reg property,
> > and that case hopefully won't happen on ARM32 or ARM64.
>
> Sure, I ment, after Liviu's patch it will become required since he is
> cleverly using it to figure out what the io mapping the bridge driver
> setup before calling the helper.
Ok. I was arguing more that we should add this dependency.
> > > I think the legacy reasons for having all those layers of translation
> > > are probably not applicable to ARM64, and it is much simpler without
> > > the extra translation step....
> > >
> > > Arnd, what do you think?
> >
> > Either I don't like it or I misunderstand you ;-)
> >
> > Most PCI drivers normally don't call ioport_map or pci_iomap, so
> > we can't just do it there. If you are thinking of calling ioport_map
>
> Okay, that was one of the 'legacy reasons'. Certainly lots of drivers
> do call pci_iomap, but if you think legacy drivers that don't are
> important to ARM64 then it makes sense to use the virtual IO window.
I think all uses of I/O space are legacy, but I don't think that
drivers doing inb/outb are more obsolete than those doing pci_iomap.
It's got more to do with the subsystem requirements, e.g. libata
requires the use of pci_iomap.
> > for every PCI device that has an I/O BAR and storing the virtual
> > address in the pci_dev resource, I don't see what that gains us
>
> Mainly we get to drop the fancy dynamic allocation stuff for the fixed
> virtual window, and it gives the option to have a 1:1 relationship
> between CPU addresses and PCI BARs.
I don't think the allocation is much of a problem, as long as we
can localize it in one function that is shared by everyone.
The problems I saw were all about explaining to people how it
works, but they really shouldn't have to know.
Arnd
^ permalink raw reply
* Re: [PATCH] checkpatch: fix spurious vendor compatible warnings
From: Florian Vaussard @ 2014-02-27 20:24 UTC (permalink / raw)
To: Joe Perches; +Cc: Andy Whitcroft, Rob Herring, devicetree, linux-kernel
In-Reply-To: <1393531808.24588.119.camel@joe-AO722>
On 02/27/2014 09:10 PM, Joe Perches wrote:
> On Thu, 2014-02-27 at 20:56 +0100, Florian Vaussard wrote:
>> With a compatible string like
>>
>> compatible = "foo";
>>
>> checkpatch will currently try to find "foo" in vendor-prefixes.txt,
>> which is wrong since the vendor prefix is empty in this specific case.
>>
>> Skip the vendor test if the compatible is not like
>>
>> compatible = "vendor,something";
>>
>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>> ---
>> scripts/checkpatch.pl | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
>> index 464dcef..35ec185 100755
>> --- a/scripts/checkpatch.pl
>> +++ b/scripts/checkpatch.pl
>> @@ -2058,6 +2058,7 @@ sub process {
>> my $vendor = $compat;
>> my $vendor_path = $dt_path . "vendor-prefixes.txt";
>> next if (! -f $vendor_path);
>> + next if not $vendor =~ /^[a-zA-Z0-9]+\,.*/;
>> $vendor =~ s/^([a-zA-Z0-9]+)\,.*/$1/;
>> `grep -Eq "$vendor" $vendor_path`;
>> if ( $? >> 8 ) {
>
> Some vendor names have dashes.
> I don't know if underscores are allowed.
>
> $ grep -rP --include=*.[ch] -oh "compatible\s*=\s*\"[^,]+,\w" * | \
> sed -r -e 's/\s//g' -e 's/,.$//' | sort | uniq -c | grep "[_-]"
> 1 compatible="active-semi
> 8 compatible="asahi-kasei
>
Good catch. In ePAPR v1.1, I could not find any strict requirement. It
is just saying:
The recommended format is “manufacturer,model”, where manufacturer is a
string describing the name of the manufacturer (such as a stock ticker
symbol), and model specifies the model number.
If I am not mistaking, the stock ticker symbol will not contain exotic
characters, but it is not always available. So we should probably add
the '-. I am not sure for the '_'.
Florian
^ permalink raw reply
* [PATCH v2 0/31] Add additional sandbox features and infrastructure
From: Simon Glass @ 2014-02-27 20:25 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: u-boot-review-hpIqsD4AKlfQT0dZR+AlfA, Simon Glass, Mike Frysinger,
Devicetree Discuss, Jagannadha Sutradharudu Teki,
Jagannadha Sutradharudu Teki
At present sandbox only supports a basic set of features. To help address
this, a recent series added SPI and SPI flash support; this series expands
the coverage further.
Firstly SDL is used to provide LCD and audio support. Sandbox gains its own
LCD driver which can display images, host a command line, etc. The audio
support is basic and needs additional work, but it is a starting point.
SDL also provides a keyboard emulation (using the Chrome OS EC code as a
base).
Secondly a TPM emulation is added. This does not include all features (the
implementation is quite simplistic) but it is enough to do basic secure
boot operations.
Finally, various pieces of useful infrastructure are added, including:
- loading and saving of the emulated SDRAM to permit test runs to carry
over state
- loading and saving of general sandbox state (for example a driver can
save its stage and reload it on the next run)
- support for using bootm to load a kernel
- providing a device tree for use by sandbox
- a means to jump to another U-Boot while preserving state (useful for
test environments which want to run a series of tests with
script-selectable state)
Major functions which still remain without sandbox support are I2C,
networking and USB.
Note:
Much of this series was sent out in November. Due to problems with the
LCD side it was not ready for the last release, although about a dozen
patches from the series were applied. I have rebased and tidied things
up. U-Boot now starts by default without the LCD visible since for
much sandbox testing we don't want the LCD. The Chrome OS EC code has been
updated and tidied up and full keyboard support is now present in the LCD
window.
Changes in v2:
- Add new patch to adjust #ifdef position in cros_ec
- Add new patch to sync with latest Chrome OS EC version
- Add new patches to bring in protocol v3 support
- Rebase to master
- Update series to take account of patches now merges from original series
Randall Spangler (2):
cros_ec: Clean up multiple EC protocol support
cros_ec: spi: Add support for EC protocol version 3
Simon Glass (27):
Use a const pointer for map_to_sysmem()
sandbox: Increase memory size to 32MB
sandbox: Build a device tree file for sandbox
sandbox: Use os functions to read host device tree
sandbox: dts: Add display and keyboard to sandbox
cros_ec: Add an enum for the number of flash regions
cros_ec: Add a function for reading a flash map entry
cros_ec: Add a function for decoding the Chrome OS EC flashmap
cros_ec: Support systems with no EC interrupt
cros_ec: Move #ifdef to permit flash region access
cros_ec: Sync up with latest Chrome OS EC version
cros_ec: Add base support for protocol v3
cros_ec: Correct comparison between signed and unsigned numbers
cros_ec: sandbox: Add Chrome OS EC emulation
sandbox: Plumb in Chrome OS EC emulation
cros_ec: Implement I2C pass-through
sandbox: Add os_jump_to_image() to run another executable
sandbox: Add -j option to indicate a jump from a previous U-Boot
sandbox: Add SDL library for LCD, keyboard, audio
sandbox: Add a simple sound driver
sandbox: Add LCD driver
sound: Move Samsung-specific code into its own file
sandbox: Deal with conflicting getenv() for SDL
sandbox: Allow Ctrl-C to work in sandbox
sandbox: Add options to clean up temporary files
sandbox: Add implementation of spi_setup_slave_fdt()
sandbox: config: Enable cros_ec emulation and related items
Vadim Bendebury (2):
cros_ec: Move EC interface into common library
cros_ec: Drop old EC version support from EC driver
Makefile | 3 +-
arch/sandbox/config.mk | 5 +
arch/sandbox/cpu/Makefile | 3 +
arch/sandbox/cpu/cpu.c | 2 +-
arch/sandbox/cpu/os.c | 108 ++++-
arch/sandbox/cpu/sdl.c | 341 ++++++++++++++
arch/sandbox/cpu/start.c | 60 +++
arch/sandbox/cpu/state.c | 6 +-
arch/sandbox/dts/Makefile | 11 +
arch/sandbox/dts/sandbox.dts | 125 ++++++
arch/sandbox/include/asm/arch-sandbox/sound.h | 14 +
arch/sandbox/include/asm/sdl.h | 118 +++++
arch/sandbox/include/asm/state.h | 29 +-
arch/sandbox/include/asm/u-boot-sandbox.h | 3 +
board/samsung/common/board.c | 29 +-
board/samsung/smdk5250/exynos5-dt.c | 1 -
board/sandbox/sandbox/sandbox.c | 49 ++-
common/Makefile | 1 +
common/board_f.c | 48 +-
common/cros_ec.c | 44 ++
common/lcd.c | 21 +-
disk/part.c | 17 -
doc/device-tree-bindings/video/sandbox-fb.txt | 13 +
drivers/input/cros_ec_keyb.c | 34 +-
drivers/misc/Makefile | 1 +
drivers/misc/cros_ec.c | 611 +++++++++++++++++++++++---
drivers/misc/cros_ec_i2c.c | 64 ++-
drivers/misc/cros_ec_lpc.c | 80 +---
drivers/misc/cros_ec_sandbox.c | 559 +++++++++++++++++++++++
drivers/misc/cros_ec_spi.c | 30 ++
drivers/serial/sandbox.c | 10 +-
drivers/sound/Makefile | 4 +-
drivers/sound/sandbox.c | 23 +
drivers/sound/sound-i2s.c | 208 +++++++++
drivers/sound/sound.c | 221 +---------
drivers/spi/sandbox_spi.c | 13 +
drivers/video/Makefile | 1 +
drivers/video/sandbox_sdl.c | 79 ++++
include/common.h | 6 +
include/configs/exynos5250-dt.h | 1 +
include/configs/sandbox.h | 41 +-
include/cros_ec.h | 94 +++-
include/cros_ec_message.h | 2 +-
include/ec_commands.h | 348 +++++++++++++--
include/fdtdec.h | 20 +
include/lcd.h | 3 +
include/os.h | 27 +-
include/sound.h | 9 +
lib/fdtdec.c | 26 ++
49 files changed, 3032 insertions(+), 534 deletions(-)
create mode 100644 arch/sandbox/cpu/sdl.c
create mode 100644 arch/sandbox/dts/Makefile
create mode 100644 arch/sandbox/dts/sandbox.dts
create mode 100644 arch/sandbox/include/asm/arch-sandbox/sound.h
create mode 100644 arch/sandbox/include/asm/sdl.h
create mode 100644 common/cros_ec.c
create mode 100644 doc/device-tree-bindings/video/sandbox-fb.txt
create mode 100644 drivers/misc/cros_ec_sandbox.c
create mode 100644 drivers/sound/sandbox.c
create mode 100644 drivers/sound/sound-i2s.c
create mode 100644 drivers/video/sandbox_sdl.c
--
1.9.0.279.gdc9e3eb
--
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 05/31] sandbox: dts: Add display and keyboard to sandbox
From: Simon Glass @ 2014-02-27 20:25 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: u-boot-review-hpIqsD4AKlfQT0dZR+AlfA, Simon Glass,
Devicetree Discuss
In-Reply-To: <1393532785-9020-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Add an LCD display and keyboard to the sandbox device tree so that these
features can be used.
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v2: None
arch/sandbox/dts/sandbox.dts | 95 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 95 insertions(+)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index ea4b8ad..11afbc2 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -27,4 +27,99 @@
sides = <6>;
};
+ host@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "sandbox,host-emulation";
+ cros-ec@0 {
+ reg = <0>;
+ compatible = "google,cros-ec";
+
+ /*
+ * This describes the flash memory within the EC. Note
+ * that the STM32L flash erases to 0, not 0xff.
+ */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ flash@8000000 {
+ reg = <0x08000000 0x20000>;
+ erase-value = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Information for sandbox */
+ ro {
+ reg = <0 0xf000>;
+ };
+ wp-ro {
+ reg = <0xf000 0x1000>;
+ };
+ rw {
+ reg = <0x10000 0x10000>;
+ };
+ };
+ };
+ };
+
+ lcd {
+ compatible = "sandbox,lcd-sdl";
+ xres = <800>;
+ yres = <600>;
+ };
+
+ cros-ec-keyb {
+ compatible = "google,cros-ec-keyb";
+ google,key-rows = <8>;
+ google,key-columns = <13>;
+ google,repeat-delay-ms = <240>;
+ google,repeat-rate-ms = <30>;
+ google,ghost-filter;
+ /*
+ * Keymap entries take the form of 0xRRCCKKKK where
+ * RR=Row CC=Column KKKK=Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
+ linux,keymap = <
+ /* CAPSLCK F1 B F10 */
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
+ /* N = R_ALT ESC */
+ 0x00060031 0x0008000d 0x000a0064 0x01010001
+ /* F4 G F7 H */
+ 0x0102003e 0x01030022 0x01040041 0x01060023
+ /* ' F9 BKSPACE L_CTRL */
+ 0x01080028 0x01090043 0x010b000e 0x0200001d
+ /* TAB F3 T F6 */
+ 0x0201000f 0x0202003d 0x02030014 0x02040040
+ /* ] Y 102ND [ */
+ 0x0205001b 0x02060015 0x02070056 0x0208001a
+ /* F8 GRAVE F2 5 */
+ 0x02090042 0x03010029 0x0302003c 0x03030006
+ /* F5 6 - \ */
+ 0x0304003f 0x03060007 0x0308000c 0x030b002b
+ /* R_CTRL A D F */
+ 0x04000061 0x0401001e 0x04020020 0x04030021
+ /* S K J ; */
+ 0x0404001f 0x04050025 0x04060024 0x04080027
+ /* L ENTER Z C */
+ 0x04090026 0x040b001c 0x0501002c 0x0502002e
+ /* V X , M */
+ 0x0503002f 0x0504002d 0x05050033 0x05060032
+ /* L_SHIFT / . SPACE */
+ 0x0507002a 0x05080035 0x05090034 0x050B0039
+ /* 1 3 4 2 */
+ 0x06010002 0x06020004 0x06030005 0x06040003
+ /* 8 7 0 9 */
+ 0x06050009 0x06060008 0x0608000b 0x0609000a
+ /* L_ALT DOWN RIGHT Q */
+ 0x060a0038 0x060b006c 0x060c006a 0x07010010
+ /* E R W I */
+ 0x07020012 0x07030013 0x07040011 0x07050017
+ /* U R_SHIFT P O */
+ 0x07060016 0x07070036 0x07080019 0x07090018
+ /* UP LEFT */
+ 0x070b0067 0x070c0069>;
+ };
+
};
--
1.9.0.279.gdc9e3eb
--
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 related
* Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
From: Felipe Balbi @ 2014-02-27 20:50 UTC (permalink / raw)
To: Loc Ho
Cc: balbi, Kishon Vijay Abraham I, Tejun Heo, Olof Johansson,
Arnd Bergmann, linux-kernel, Linux SCSI List,
linux-ide@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Don Dutile, Jon Masters,
patches@apm.com
In-Reply-To: <CAPw-ZT=F07=T0=z=iT=hxJ0+609RBDYRL=MXF5dQoEowLjsRjQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
Hi,
On Thu, Feb 27, 2014 at 11:57:44AM -0800, Loc Ho wrote:
> > On Thu, Feb 27, 2014 at 11:14:05AM -0700, Loc Ho wrote:
> >> This patch adds function set_speed to the generic PHY framework operation
> >> structure. This function can be called to instruct the PHY underlying layer
> >> at specified lane to configure for specified speed in hertz.
> >
> > why ? looks like clk_set_rate() is your friend here. Can you be more
> > descriptive of the use case ? When will this be used ?
> >
>
> The phy_set_speed is used to configure the operation speed of the PHY
> at run-time. The clock interface in general is used to configure the
> clock input to the IP. I don't believe they are the same thing. Maybe
> it will be clear in my response to your second email
The problem with this is that you end up adding SATA-specific details to
something which is supposed to be generic. After negoatiation, don't you
get any interrupt from your PHY indicating that link speed negotiation
is done ? Or is that IRQ only on AHCI IP ?
cheers
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH V2 1/3] dt: palmas: support IRQ inversion at the board level
From: Stephen Warren @ 2014-02-27 20:51 UTC (permalink / raw)
To: Samuel Ortiz, Lee Jones
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, J Keerthy, Ian Lartey,
Stephen Warren
From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Some boards or SoCs have an inverter between the PMIC IRQ output pin and
the IRQ controller input signal.
The IRQ specifier in DT is meant to represent the IRQ flags at the input
to the IRQ controller.
The Palmas HW's IRQ output has configurable polarity. Software needs to
know which polarity to choose for the IRQ output. Software may be tempted
to extract the IRQ polarity from the IRQ specifier in order to make this
choice.
That approach works fine if the IRQ signal is routed directly from the
PMIC to the IRQ controller with no intervening logic. However, if the
signal is inverted between the two, this approach gets the wrong answer.
Add an additional optional DT property which indicates that such an
inversion occurs. This allows DT to give complete information about the
desired IRQ output polarity to software.
An alternative would have been to add a new non-optional DT parameter to
indicate the exact desired output polarity. However, this would have been
an incompatible change to the DT binding.
Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3.
---
Documentation/devicetree/bindings/mfd/palmas.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt
index e5f0f8303461..76ec509d5f87 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -18,6 +18,12 @@ Required properties:
ti,tps659038
and also the generic series names
ti,palmas
+- interrupts : Should contain a single entry for the IRQ output.
+- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ
+ output should be set to the opposite of the polarity indicated by the IRQ
+ specifier in the interrupts property. If absent, the polarity should be
+ configured to match. This allows the representation of an inverter between
+ the Palmas IRQ output and the interrupt parent's IRQ input.
- interrupt-controller : palmas has its own internal IRQs
- #interrupt-cells : should be set to 2 for IRQ number and flags
The first cell is the IRQ number.
--
1.8.1.5
^ permalink raw reply related
* [PATCH V2 2/3] mfd: palmas: support IRQ inversion at the board level
From: Stephen Warren @ 2014-02-27 20:51 UTC (permalink / raw)
To: Samuel Ortiz, Lee Jones
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, J Keerthy, Ian Lartey,
Stephen Warren
In-Reply-To: <1393534281-30759-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Implement the new DT property ti,irq-externally-inverted, and add an
equivalent platform data field to match. This allows the driver to
correctly automatically configure the IRQ output polarity when the board
or SoC contains an inverter between the Palmas IRQ output and IRQ
controller input.
Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3.
If this patch (and likely 1/3 too) could be applied to its own branch
(w/ signed tag) in the MFD tree, that would great; then I can pull patch
it into the Tegra tree so that I can apply patch 3/3 on top. Thanks.
---
drivers/mfd/palmas.c | 4 ++++
include/linux/mfd/palmas.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index d280d789e55a..f4ea932adf8d 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -293,6 +293,8 @@ static int palmas_set_pdata_irq_flag(struct i2c_client *i2c,
}
pdata->irq_flags = irqd_get_trigger_type(irq_data);
+ pdata->irq_external_inversion = of_property_read_bool(i2c->dev.of_node,
+ "ti,irq-externally-inverted");
dev_info(&i2c->dev, "Irq flag is 0x%08x\n", pdata->irq_flags);
return 0;
}
@@ -447,6 +449,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
else
reg = 0;
+ if (pdata->irq_external_inversion)
+ reg ^= PALMAS_POLARITY_CTRL_INT_POLARITY;
ret = palmas_update_bits(palmas, PALMAS_PU_PD_OD_BASE,
PALMAS_POLARITY_CTRL, PALMAS_POLARITY_CTRL_INT_POLARITY,
reg);
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 9974e387e483..2fdf08c50a48 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -292,6 +292,7 @@ struct palmas_clk_platform_data {
struct palmas_platform_data {
int irq_flags;
+ bool irq_external_inversion;
int gpio_base;
/* bit value to be loaded to the POWER_CTRL register */
--
1.8.1.5
^ permalink raw reply related
* [PATCH V2 3/3] ARM: tegra: fix Dalmore PMIC IRQ polarity
From: Stephen Warren @ 2014-02-27 20:51 UTC (permalink / raw)
To: Samuel Ortiz, Lee Jones
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA, J Keerthy, Ian Lartey,
Stephen Warren
In-Reply-To: <1393534281-30759-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
The Tegra PMC's resume-from-sleep logic wants an active-low IRQ input
from the PMIC. However, the PMIC IRQ is also routed to the GIC, which
only supports active high IRQs (or rising edge). Hence, the signal must
be inverted in the PMC before being routed to the GIC. This implies that
the PMC DT property nvidia,invert-interrupt must be set, and it is.
The PMIC's DT interrupts property must represent the IRQ level at the
GIC, since that is the PMIC's parent IRQ controller. Fix the PMIC's
interrupts property to correctly describe the GIC input polarity.
However, the PMIC IRQ output's polarity is programmable in HW, and by
default follows the parent IRQ controller's input polarity. We need to
have an active-low output due to the inversion inside the Tegra PMC.
Hence, add the ti,irq-externally-inverted property to the PMIC.
Reported-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
v2: No change.
---
arch/arm/boot/dts/tegra114-dalmore.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 8de543777882..2977206cafc9 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -893,7 +893,8 @@
palmas: tps65913@58 {
compatible = "ti,palmas";
reg = <0x58>;
- interrupts = <0 86 IRQ_TYPE_LEVEL_LOW>;
+ interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
+ ti,irq-externally-inverted;
#interrupt-cells = <2>;
interrupt-controller;
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH V2 1/3] dt: palmas: support IRQ inversion at the board level
From: Graeme Gregory @ 2014-02-27 21:02 UTC (permalink / raw)
To: Stephen Warren
Cc: Samuel Ortiz, Lee Jones, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Pawel Moll,
Ian Campbell, J Keerthy, Ian Lartey, Rob Herring, Kumar Gala,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1393534281-30759-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
On Thu, Feb 27, 2014 at 01:51:19PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Some boards or SoCs have an inverter between the PMIC IRQ output pin and
> the IRQ controller input signal.
>
> The IRQ specifier in DT is meant to represent the IRQ flags at the input
> to the IRQ controller.
>
> The Palmas HW's IRQ output has configurable polarity. Software needs to
> know which polarity to choose for the IRQ output. Software may be tempted
> to extract the IRQ polarity from the IRQ specifier in order to make this
> choice.
>
> That approach works fine if the IRQ signal is routed directly from the
> PMIC to the IRQ controller with no intervening logic. However, if the
> signal is inverted between the two, this approach gets the wrong answer.
>
> Add an additional optional DT property which indicates that such an
> inversion occurs. This allows DT to give complete information about the
> desired IRQ output polarity to software.
>
> An alternative would have been to add a new non-optional DT parameter to
> indicate the exact desired output polarity. However, this would have been
> an incompatible change to the DT binding.
>
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Acked-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3.
> ---
> Documentation/devicetree/bindings/mfd/palmas.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt
> index e5f0f8303461..76ec509d5f87 100644
> --- a/Documentation/devicetree/bindings/mfd/palmas.txt
> +++ b/Documentation/devicetree/bindings/mfd/palmas.txt
> @@ -18,6 +18,12 @@ Required properties:
> ti,tps659038
> and also the generic series names
> ti,palmas
> +- interrupts : Should contain a single entry for the IRQ output.
> +- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ
> + output should be set to the opposite of the polarity indicated by the IRQ
> + specifier in the interrupts property. If absent, the polarity should be
> + configured to match. This allows the representation of an inverter between
> + the Palmas IRQ output and the interrupt parent's IRQ input.
This has got to be the wrong way to do things, all this leads to is every
device doing this property in its own way and having totally inconsistent
properties all meaning the same thing.
If there is some other hardware inverting lines then there should be
a generic binding for this in DT. This is not describing the palmas hardware
but some external object to the palmas.
Graeme
> - interrupt-controller : palmas has its own internal IRQs
> - #interrupt-cells : should be set to 2 for IRQ number and flags
> The first cell is the IRQ number.
> --
> 1.8.1.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/8] ARM: dts: omap3-overo: Use complete poweroff
From: Nishanth Menon @ 2014-02-27 21:07 UTC (permalink / raw)
To: florian.vaussard, Tony Lindgren, Benoit Cousson
Cc: linux-omap, linux-arm-kernel, devicetree@vger.kernel.org
In-Reply-To: <530FA497.7000407@epfl.ch>
+devicetree list.
On 02/27/2014 02:48 PM, Florian Vaussard wrote:
> On 02/27/2014 09:38 PM, Nishanth Menon wrote:
>> On 02/27/2014 02:30 PM, Florian Vaussard wrote:
>>> Currently, the TWL4030 PMIC does not completely poweroff the processor.
>>> Commit b0fc1da4d0359d3cce8f12e0f014aed0704ae202 introduced the necessary
>>> binding to do this, so use it.
>>>
>>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>>> ---
>>> arch/arm/boot/dts/omap3-overo.dtsi | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-overo.dtsi b/arch/arm/boot/dts/omap3-overo.dtsi
>>> index aea64c0..018e1e0 100644
>>> --- a/arch/arm/boot/dts/omap3-overo.dtsi
>>> +++ b/arch/arm/boot/dts/omap3-overo.dtsi
>>> @@ -73,6 +73,11 @@
>>> codec {
>>> };
>>> };
>>> +
>>> + twl_power: power {
>>> + compatible = "ti,twl4030-power";
>>> + ti,use_poweroff;
>>> + };
>>> };
>>> };
>>>
>>>
>> Urrgh.. this slipped past.. :(
>>
>> ti,system-power-controller is traditionally used for other PMICs from
>> TI to indicate that poweroff functionality will be provided by the
>> PMIC driver. similar approach is taken by Maxim as well.. I know the
>> commit introducing the binding has been around for long, but
>> considering that we do not have a single dts using this yet, should we
>> consider adding "ti,system-power-controller"(as against removing
>> ti,use_poweroff - so that older down stream dtbs still work) and using
>> it in the new code?
>>
>
> It does make sense, so I am not against it. My only concern is that I
> find the name to be slightly less easy to understand, but I can live
> with it :-)
:)
>
> I do not remember if DT maintainers came up with a clear policy to
> deprecate a binding.
I dont think we can depreciate a binding [1] - as you mentioned -
renaming the property is probably what is appropriate, but introducing
a new one which has the same behavior as the old one does'nt seem
covered either.. considering potential downstream kernel usage, I'd
suggest additional property inline with today's convention.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
From: Loc Ho @ 2014-02-27 21:09 UTC (permalink / raw)
To: balbi
Cc: Kishon Vijay Abraham I, Tejun Heo, Olof Johansson, Arnd Bergmann,
linux-kernel, Linux SCSI List, linux-ide@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Don Dutile, Jon Masters, patches@apm.com
In-Reply-To: <20140227205039.GE5375@saruman.home>
Hi,
>> >> This patch adds function set_speed to the generic PHY framework operation
>> >> structure. This function can be called to instruct the PHY underlying layer
>> >> at specified lane to configure for specified speed in hertz.
>> >
>> > why ? looks like clk_set_rate() is your friend here. Can you be more
>> > descriptive of the use case ? When will this be used ?
>> >
>>
>> The phy_set_speed is used to configure the operation speed of the PHY
>> at run-time. The clock interface in general is used to configure the
>> clock input to the IP. I don't believe they are the same thing. Maybe
>> it will be clear in my response to your second email
>
> The problem with this is that you end up adding SATA-specific details to
> something which is supposed to be generic.
Setting the operation speed is pretty generic from an interface point
of view. An generic multi-purpose PHY can support multiple speed. If
the upper layer wish to operate at an specified speed (say for testing
purpose and etc), it can be allowed.
> After negoatiation, don't you
> get any interrupt from your PHY indicating that link speed negotiation
> is done ? Or is that IRQ only on AHCI IP ?
There is NO interrupt from the PHY. The IRQ is assoicated with the
AHCI IP. With SATA host flow, it starts off with an COMRESET to start
the link negotiation. At that point, it will poll for completion.
Any other concerns?
-Loc
^ permalink raw reply
* [PATCH v2 0/7] ARM: dma: Support dma-ranges and dma-coherent
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd
Cc: devicetree, Grygorii Strashko, Russell King, Tony Lindgren,
linus.walleij, magnus.damm, Olof Johansson, robh+dt,
Santosh Shilimkar, Greg Ungerer, grant.likely, linux-arm-kernel
Following the RFC [1], [2] comments, suggestions and some IRC discussion
with Arnd Bergmann, here is the refreshed series. Attempt is to use dma-ranges
and dma-coherent properties to setup the dma for ARM platforms.
Platforms needing more funky stuff than the generic ones can use per
platform device callbacks. Differnt buses like PCIE dma parsing still needs
to be addressed though.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
CC: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Grygorii Strashko (5):
ARM: mm: Introduce archdata.dma_pfn_offset
ARM: mm: Remove unsed dma_to_virt()
dma: of: introduce of_dma_get_range() helper
ARM: of: introduce common routine for DMA configuration
ARM: dts: keystone: Use dma-ranges property
Santosh Shilimkar (2):
dma: of: introduce of_dma_is_coherent() helper
ARM: dts: keystone: Udate USB node for dma properties
arch/arm/boot/dts/keystone.dtsi | 3 +
arch/arm/include/asm/device.h | 1 +
arch/arm/include/asm/dma-mapping.h | 25 +++----
arch/arm/include/asm/prom.h | 3 +
arch/arm/kernel/devtree.c | 61 +++++++++++++++
arch/arm/mach-iop13xx/include/mach/memory.h | 11 ---
arch/arm/mach-ks8695/include/mach/memory.h | 2 -
arch/arm/mach-omap1/include/mach/memory.h | 4 -
drivers/dma/of-dma.c | 108 +++++++++++++++++++++++++++
drivers/of/platform.c | 5 +-
include/linux/of.h | 2 +-
include/linux/of_dma.h | 13 ++++
12 files changed, 205 insertions(+), 33 deletions(-)
Regards,
Santosh
[1] http://www.spinics.net/lists/arm-kernel/msg304555.html
[2] http://www.spinics.net/lists/arm-kernel/msg310562.html
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/7] ARM: mm: Introduce archdata.dma_pfn_offset
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd
Cc: devicetree, Grygorii Strashko, Russell King, linus.walleij,
magnus.damm, Olof Johansson, robh+dt, Santosh Shilimkar,
grant.likely, linux-arm-kernel
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
In most of cases DMA addresses can be performed using offset value of
Bus address space relatively to physical address space as following:
PFN->DMA:
__pfn_to_phys(pfn + [-]dma_pfn_offset)
DMA->PFN:
__phys_to_pfn(dma_addr) + [-]dma_pfn_offset
This patch introduces new field dma_pfn_offset in ARM dev_archdata
structure which has to be filed per-device at arch init time
(simplest way is to use Platform bus notifier to handle
BUS_NOTIFY_ADD_DEVICE event) and updates DMA address translation
routines in order to accommodate bus offset value by default.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/include/asm/device.h | 1 +
arch/arm/include/asm/dma-mapping.h | 17 +++++++++++++----
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..861961c 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -8,6 +8,7 @@
struct dev_archdata {
struct dma_map_ops *dma_ops;
+ unsigned long dma_pfn_offset;
#ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
#endif
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index e701a4d..247ed72 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -58,22 +58,31 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- return (dma_addr_t)__pfn_to_bus(pfn);
+ if (!dev)
+ return DMA_ERROR_CODE;
+ return (dma_addr_t)__pfn_to_bus(pfn - dev->archdata.dma_pfn_offset);
}
static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
{
- return __bus_to_pfn(addr);
+ if (!dev)
+ return 0;
+ return __bus_to_pfn(addr) + dev->archdata.dma_pfn_offset;
}
static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
{
- return (void *)__bus_to_virt((unsigned long)addr);
+ if (!dev)
+ return NULL;
+ return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
}
static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
{
- return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
+ if (!dev)
+ return DMA_ERROR_CODE;
+ return pfn_to_dma(dev,
+ __bus_to_pfn(__virt_to_bus((unsigned long)(addr))));
}
#else
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/7] ARM: mm: Remove unsed dma_to_virt()
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson, Greg Ungerer, Tony Lindgren, Santosh Shilimkar
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
From: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Remove dma_to_virt() as there are no in-tree users of it.
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Greg Ungerer <gerg-JBU5SbJe1FlAfugRpC6u6w@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
---
arch/arm/include/asm/dma-mapping.h | 14 +-------------
arch/arm/mach-iop13xx/include/mach/memory.h | 11 -----------
arch/arm/mach-ks8695/include/mach/memory.h | 2 --
arch/arm/mach-omap1/include/mach/memory.h | 4 ----
4 files changed, 1 insertion(+), 30 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 247ed72..e365158 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -51,7 +51,7 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
#endif
/*
- * dma_to_pfn/pfn_to_dma/dma_to_virt/virt_to_dma are architecture private
+ * dma_to_pfn/pfn_to_dma/virt_to_dma are architecture private
* functions used internally by the DMA-mapping API to provide DMA
* addresses. They must not be used by drivers.
*/
@@ -70,13 +70,6 @@ static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
return __bus_to_pfn(addr) + dev->archdata.dma_pfn_offset;
}
-static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
-{
- if (!dev)
- return NULL;
- return (void *)__bus_to_virt(__pfn_to_bus(dma_to_pfn(dev, addr)));
-}
-
static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
{
if (!dev)
@@ -96,11 +89,6 @@ static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
return __arch_dma_to_pfn(dev, addr);
}
-static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
-{
- return __arch_dma_to_virt(dev, addr);
-}
-
static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
{
return __arch_virt_to_dma(dev, addr);
diff --git a/arch/arm/mach-iop13xx/include/mach/memory.h b/arch/arm/mach-iop13xx/include/mach/memory.h
index 7c032d0..1223c85 100644
--- a/arch/arm/mach-iop13xx/include/mach/memory.h
+++ b/arch/arm/mach-iop13xx/include/mach/memory.h
@@ -36,17 +36,6 @@ static inline void __iomem *__lbus_to_virt(dma_addr_t x)
#define is_lbus_device(dev) \
(dev && strncmp(dev->bus->name, "platform", 8) == 0)
-#define __arch_dma_to_virt(dev, addr) \
- ({ \
- void * __virt; \
- dma_addr_t __dma = addr; \
- if (is_lbus_device(dev) && __is_lbus_dma(__dma)) \
- __virt = __lbus_to_virt(__dma); \
- else \
- __virt = (void *)__phys_to_virt(__dma); \
- __virt; \
- })
-
#define __arch_virt_to_dma(dev, addr) \
({ \
void * __virt = addr; \
diff --git a/arch/arm/mach-ks8695/include/mach/memory.h b/arch/arm/mach-ks8695/include/mach/memory.h
index 95e731a..f42477c 100644
--- a/arch/arm/mach-ks8695/include/mach/memory.h
+++ b/arch/arm/mach-ks8695/include/mach/memory.h
@@ -31,8 +31,6 @@
/* Platform-bus mapping */
extern struct bus_type platform_bus_type;
#define is_lbus_device(dev) (dev && dev->bus == &platform_bus_type)
-#define __arch_dma_to_virt(dev, x) ({ (void *) (is_lbus_device(dev) ? \
- __phys_to_virt(x) : __bus_to_virt(x)); })
#define __arch_virt_to_dma(dev, x) ({ is_lbus_device(dev) ? \
(dma_addr_t)__virt_to_phys((unsigned long)x) \
: (dma_addr_t)__virt_to_bus(x); })
diff --git a/arch/arm/mach-omap1/include/mach/memory.h b/arch/arm/mach-omap1/include/mach/memory.h
index 3c25305..73f86db 100644
--- a/arch/arm/mach-omap1/include/mach/memory.h
+++ b/arch/arm/mach-omap1/include/mach/memory.h
@@ -43,10 +43,6 @@
__phys_to_pfn(__dma); \
})
-#define __arch_dma_to_virt(dev, addr) ({ (void *) (is_lbus_device(dev) ? \
- lbus_to_virt(addr) : \
- __phys_to_virt(addr)); })
-
#define __arch_virt_to_dma(dev, addr) ({ unsigned long __addr = (unsigned long)(addr); \
(dma_addr_t) (is_lbus_device(dev) ? \
virt_to_lbus(__addr) : \
--
1.7.9.5
--
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 related
* [PATCH v2 3/7] dma: of: introduce of_dma_get_range() helper
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson, Santosh Shilimkar
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
From: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
The of_dma_get_range() allows to find "dma-range" property for
the specified device and parse it.
dma-ranges format:
DMA addr (dma_addr) : naddr cells
CPU addr (phys_addr_t) : pna cells
size : nsize cells
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
---
drivers/dma/of-dma.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of_dma.h | 8 +++++
2 files changed, 94 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..9b51768 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -17,6 +17,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_dma.h>
+#include <linux/of_address.h>
static LIST_HEAD(of_dma_list);
static DEFINE_MUTEX(of_dma_lock);
@@ -218,3 +219,88 @@ struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_get_range - Get DMA range info
+ * @np: device node to get DMA range info
+ * @dma_addr: pointer to store initial DMA address of DMA range
+ * @paddr: pointer to store initial CPU address of DMA range
+ * @size: pointer to store size of DMA range
+ *
+ * Look in bottom up direction for the first "dma-range" property
+ * and parse it.
+ * dma-ranges format:
+ * DMA addr (dma_addr) : naddr cells
+ * CPU addr (phys_addr_t) : pna cells
+ * size : nsize cells
+ *
+ * It returns -ENODEV if "dma-ranges" property was not found
+ * for this device in DT.
+ */
+extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size)
+{
+ struct device_node *node = np;
+ const u32 *ranges = NULL;
+ int len, naddr, nsize, pna;
+ int ret = 0;
+
+ if (!node)
+ return -EINVAL;
+
+ while (1) {
+ naddr = of_n_addr_cells(node);
+ nsize = of_n_size_cells(node);
+ node = of_get_next_parent(node);
+ if (!node)
+ break;
+
+ ranges = of_get_property(node, "dma-ranges", &len);
+
+ /* Ignore empty ranges, they imply no translation required */
+ if (ranges && len > 0)
+ break;
+
+ /*
+ * At least empty ranges has to be defined for parent node if
+ * DMA is supported
+ */
+ if (!ranges)
+ break;
+ }
+
+ if (!ranges) {
+ pr_debug("%s: no dma-ranges found for node(%s)\n",
+ __func__, np->full_name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ len /= sizeof(u32);
+
+ pna = of_n_addr_cells(node);
+
+ /* dma-ranges format:
+ * DMA addr : naddr cells
+ * CPU addr : pna cells
+ * size : nsize cells
+ */
+ *dma_addr = of_read_number(ranges, naddr);
+ *paddr = of_translate_dma_address(np, ranges);
+ if (*paddr == OF_BAD_ADDR) {
+ pr_err("%s: translation of DMA address(%#08x) to CPU address failed node(%s)\n",
+ __func__, *dma_addr, np->full_name);
+ ret = -EINVAL;
+ }
+
+ *size = of_read_number(ranges + naddr + pna, nsize);
+
+ pr_debug("dma_addr(%08x) cpu_addr(%pa) size(%pa)\n",
+ *dma_addr, paddr, size);
+
+out:
+ of_node_put(node);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_dma_get_range);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..f04171a 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,9 @@ extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+
+extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -66,6 +69,11 @@ static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_s
return NULL;
}
+static inline int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
+ phys_addr_t *paddr, phys_addr_t *size);
+{
+ return -ENODEV;
+}
#endif
#endif /* __LINUX_OF_DMA_H */
--
1.7.9.5
--
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 related
* [PATCH v2 4/7] dma: of: introduce of_dma_is_coherent() helper
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Santosh Shilimkar, Russell King,
Olof Johansson
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
The of_dma_is_coherent() helper parses the given DT device
node to see if the "dma-coherent" property is supported and
returns true or false accordingly.
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
---
drivers/dma/of-dma.c | 22 ++++++++++++++++++++++
include/linux/of_dma.h | 5 +++++
2 files changed, 27 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 9b51768..c5958d1 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -304,3 +304,25 @@ out:
return ret;
}
EXPORT_SYMBOL_GPL(of_dma_get_range);
+
+/**
+ * of_dma_is_coherent - Check if device is coherent
+ * @np: device node
+ *
+ * It returns true if "dma-coherent" property was found
+ * for this device in DT.
+ */
+bool of_dma_is_coherent(struct device_node *np)
+{
+ struct device_node *node = np;
+
+ while (node) {
+ if (of_property_read_bool(node, "dma-coherent")) {
+ of_node_put(node);
+ return true;
+ }
+ node = of_get_next_parent(node);
+ }
+ return false;
+}
+EXPORT_SYMBOL_GPL(of_dma_is_coherent);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index f04171a..6191f02 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -44,6 +44,7 @@ extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
phys_addr_t *paddr, phys_addr_t *size);
+extern bool of_dma_is_coherent(struct device_node *np);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -74,6 +75,10 @@ static inline int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
{
return -ENODEV;
}
+static inline bool of_dma_is_coherent(struct device_node *np)
+{
+ return false;
+}
#endif
#endif /* __LINUX_OF_DMA_H */
--
1.7.9.5
--
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 related
* [PATCH v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson, Santosh Shilimkar
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
From: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
This patch introduces ARM specific function arm_dt_dma_configure()
which intended to retrieve DMA configuration from DT and setup Platform
device's DMA parameters.
The DMA configuration in DT has to be specified using "dma-ranges"
and "dam-coherent" properties if supported. The DMA configuration applied
by arm_dt_dma_configure() as following:
- call of_get_dma_range() and get supported DMA range info
(dma_addr, cpu_addr, dma_size);
- if "not found" then fill dma_mask as DMA_BIT_MASK(32)
(this is default behaviour);
- if "failed" then clean up dma_mask (DMA not supported)
- if ok then update devices DMA configuration:
set dma_mask to (dma_addr + dma_size - 1)
set dma_pfn_offset to PFN_DOWN(cpu_addr - dma_addr)
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
---
arch/arm/include/asm/prom.h | 3 +++
arch/arm/kernel/devtree.c | 61 +++++++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 5 +++-
include/linux/of.h | 2 +-
4 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index b681575..1acb732 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -11,11 +11,13 @@
#ifndef __ASMARM_PROM_H
#define __ASMARM_PROM_H
+struct device;
#ifdef CONFIG_OF
extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+extern void arm_dt_dma_configure(struct device *dev);
#else /* CONFIG_OF */
@@ -26,6 +28,7 @@ static inline const struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline void arm_dt_dma_configure(struct device *dev) { }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f751714..926b5dd 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -18,6 +18,9 @@
#include <linux/of_fdt.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <linux/of_dma.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
#include <asm/cputype.h>
#include <asm/setup.h>
@@ -235,3 +238,61 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
return mdesc;
}
+
+void arm_dt_dma_configure(struct device *dev)
+{
+ dma_addr_t dma_addr;
+ phys_addr_t paddr, size;
+ dma_addr_t dma_mask;
+ int ret;
+
+ /*
+ * if dma-ranges property doesn't exist - use 32 bits DMA mask
+ * by default and don't set skip archdata.dma_pfn_offset
+ */
+ ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
+ if (ret == -ENODEV) {
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!dev->dma_mask)
+ dev->dma_mask = &dev->coherent_dma_mask;
+ return;
+ }
+
+ /* if failed - disable DMA for device */
+ if (ret < 0) {
+ dev_err(dev, "failed to configure DMA\n");
+ return;
+ }
+
+ /* DMA ranges found. Calculate and set dma_pfn_offset */
+ dev->archdata.dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
+
+ /* Configure DMA mask */
+ dev->dma_mask = kmalloc(sizeof(*dev->dma_mask), GFP_KERNEL);
+ if (!dev->dma_mask)
+ return;
+
+ dma_mask = dma_addr + size - 1;
+
+ ret = arm_dma_set_mask(dev, dma_mask);
+ if (ret < 0) {
+ dev_err(dev, "failed to set DMA mask %#08x\n", dma_mask);
+ kfree(dev->dma_mask);
+ dev->dma_mask = NULL;
+ return;
+ }
+
+ dev_dbg(dev, "dma_pfn_offset(%#08lx) dma_mask(%#016llx)\n",
+ dev->archdata.dma_pfn_offset, *dev->dma_mask);
+
+ if (of_dma_is_coherent(dev->of_node)) {
+ set_dma_ops(dev, &arm_coherent_dma_ops);
+ dev_dbg(dev, "device is dma coherent\n");
+ }
+
+ ret = dma_set_coherent_mask(dev, dma_mask);
+ if (ret < 0) {
+ dev_err(dev, "failed to set coherent DMA mask %#08x\n",
+ dma_mask);
+ }
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1da..97d5533 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -213,10 +213,13 @@ static struct platform_device *of_platform_device_create_pdata(
#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xffffffffUL;
-#endif
+#elif defined(CONFIG_ARM_LPAE)
+ arm_dt_dma_configure(&dev->dev);
+#else
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
if (!dev->dev.dma_mask)
dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+#endif
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..a321058 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -136,7 +136,7 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
return of_read_number(cell, size);
}
-#if defined(CONFIG_SPARC)
+#if defined(CONFIG_SPARC) || defined(CONFIG_ARM_LPAE)
#include <asm/prom.h>
#endif
--
1.7.9.5
--
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 related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox