Hi,
I am getting kernel uImage build issue on omap2+ log[1]
Taken kernel branch "for_3.10/dts" from
https://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
Taking reference from
https://kernel.googlesource.com/pub/scm/linux/kernel/git/tmlind/linux-omap/+/omap-for-v3.9/multipla
Le 15/03/2013 21:50, Maxime Ripard a écrit :
> From: Stefan Roese
>
> The Allwinner A10 has an ethernet controller that is advertised as
> coming from Davicom.
>
> The exact feature set of this controller is unknown, since there is no
> public documentation for this IP, and this driver is mostly
From: Stefan Roese
The Allwinner A10 has an ethernet controller that is advertised as
coming from Davicom.
The exact feature set of this controller is unknown, since there is no
public documentation for this IP, and this driver is mostly the one
published by Allwinner that has been heavily clean
On Thu, Mar 14, 2013 at 07:08:34PM +0100, Florian Fainelli wrote:
> + if (dev->err_interrupt == NO_IRQ) {
...
> + init_waitqueue_head(&dev->smi_busy_wait);
> +
> + dev->err_interrupt = platform_get_irq(pdev, 0);
> + if (dev->err_interrupt != -ENXIO) {
...
> + } else
> +
Hi,
I think you can get rid of quite a bit more of the repeated data for
most boards, see below.
* Roger Quadros [130315 08:21]:
> Add 2 platform devices for 'nop-usb-xceiv'. These will be used
> as PHYs for HS USB ports 1 and 2 so provide binding information
> for them.
>
> Use usbhs_init_phys
On 15 March 2013 17:15, Naveen Krishna Ch wrote:
> On 14 March 2013 02:10, Doug Anderson wrote:
>> Without this change the exynos adc controller needed to have its phy
>> enabled in some out-of-driver C code. Add support for specifying the
>> phy enable register by listing it in the reg list.
>>
Rob, Grant,
On 03/15/2013 10:24 AM, Jon Hunter wrote:
>
> On 03/14/2013 04:54 PM, Javier Martinez Canillas wrote:
>> Besides being used to interface with external memory devices,
>> the General-Purpose Memory Controller can be used to connect
>> Pseudo-SRAM devices such as ethernet controllers to
On 03/14/2013 04:54 PM, Javier Martinez Canillas wrote:
> Besides being used to interface with external memory devices,
> the General-Purpose Memory Controller can be used to connect
> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
> processors using the TI GPMC as a data bus.
>
> Thi
From: Javier Martinez Canillas
gpmc_probe_nor_child() calls of_platform_device_create() to create a
platform device for the NOR child. If this function fails the value
of ret is returned to the caller but this value is zero since it was
assigned the return of a previous call to gpmc_cs_program_se
When the GPMC driver is probed, we call gpmc_mem_init() to see which
chip-selects have already been configured and enabled by the boot-loader
and allocate space for them. If we fail to allocate space for one
chip-select, then we return failure from the probe and the GPMC driver
will not be availabl
With commit 21cc2bd (ARM: OMAP2+: Remove apollon board support) the
variable "boot_rom_space" is now not needed and the code surrounding
this variable can be cleaned up and simplified. Remove unnecessary
definitions and clean-up the comment as well.
Signed-off-by: Jon Hunter
---
arch/arm/mach-om
Each GPMC chip-select can be configured to map 16MB, 32MB, 64MB or 128MB
of address space. The physical base address where a chip-select starts
is also configurable and must be aligned on a boundary that is equal to
or greater than the size of the address space mapped bt the chip-select.
When enabl
When booting with device-tree, retrieve GPMC settings for NAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-nand.c | 16 +
When booting with device-tree, retrieve GPMC settings for ONENAND from
the device-tree blob. This will allow us to remove all static settings
stored in the gpmc-nand.c in the future once the migration to
device-tree is complete.
The user must now specify the ONENAND device width in the device-tree
NOR flash is not currently supported when booting with device-tree
on OMAP2+ devices. Add support to detect and configure NOR devices
when booting with device-tree.
Add documentation for the TI GPMC NOR binding.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/mtd/gpmc-nor.txt |
Some of the GPMC timings parameters are currently missing from the GPMC
device-tree binding. Add these parameters to the binding documentation
as well as code to read them.
The existing code in gpmc_read_timings_dt() is checking the value of
of_property_read_u32() and only is successful storing th
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
options.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 23 +
With the addition of the gpmc_cs_program_settings(), we no longer need
or use gpmc_cs_configure() to configure some of the GPMC chip-select
options. So rename the function to gpmc_configure() and remove code that
modifies options in the CONFIG1 register.
Signed-off-by: Jon Hunter
---
arch/arm/ma
Convert the OMAP2+ TUSB code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/usb-tusb6010.c | 43
1 file changed,
Convert the OMAP2+ SMC91x code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Move configuration of the GPMC settings outside retime function and
this does not need to be done if the timings are changed
Convert the OMAP2+ NAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
This moves the configuration of some GPMC options outside the
nand_gpmc_retime() because these options should only need to be s
Hello,
On 2/14/2013 10:34 PM, Laura Abbott wrote:
On 2/14/2013 4:45 AM, Marek Szyprowski wrote:
+name:an name given to the defined region.
+base-address:the base address of the defined region.
+size:the size of the memory region.
+linux,contiguous-region: property indicati
Convert the OMAP2+ ONENAND code to use the gpmc_cs_program_settings()
function for configuring the various GPMC options instead of directly
programming the CONFIG1 register.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/gpmc-onenand.c | 61 +++-
1 file chang
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no central structure for storing all these options
when configuring the GPMC for a given device. Some of the options are
stored in the GPMC
The GPMC has various different configuration options such as bus-width,
synchronous or asychronous mode selection, burst mode options etc.
Currently, there is no common function for configuring these options and
various devices set these options by either programming the GPMC CONFIG1
register direc
The GPMC has wait-pin signals that can be assigned to a chip-select
to monitor the ready signal of an external device. Add a variable to
indicate the total number of wait-pins for a given device. This will
allow us to detect if the wait-pin being selected is valid or not.
When booting with device-
The OMAP2+ code that configures the GPMC for ONENAND devices is copying
structures between functions unnecessarily. Avoid this by passing
pointers instead and simplify the code.
A pointer to structure "omap_onenand_platform_data" is passed to the
function omap2_onenand_calc_sync_timings(), but onl
While adding device-tree support for NOR memories, it became apparent
that there is no common way for configuring various GPMC settings for
devices that interface to the GPMC. These settings include bus-width,
synchronous/asynchronous mode, burst settings, wait monitoring etc.
Therefore, to simplif
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda.dts | 56 +
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
CC: Benoît Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-zoom.c | 32 ++--
1
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-overo.c | 32 ++--
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Ports 1 and 2, so provide binding information for them.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3touchbook.c | 38
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3stalker.c | 29 ++-
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3pandora.c |
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's RESET regulator.
VAUX2 supplies the PHY's VCC.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3evm.c | 41 +
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-igep0020.c | 66 +++
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Signed-off-by: Roger Quadros
Acked-by: Felipe Balbi
---
arch/arm/mach-omap2/board-devkit8000.c | 20
1 files changed, 12 insertions(+), 8 deletion
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-cm-t3517.c | 45 +++
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-cm-t35.c | 45 +
Add 2 platform devices for 'nop-usb-xceiv'. These will be used as a
PHY for HS USB Port 1 and 2, so provide binding information for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-am3517evm.c | 41 +
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 1, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-am3517crane.c | 38 +++
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-3630sdp.c | 48
Add 2 platform devices for 'nop-usb-xceiv'. These will be used
as PHYs for HS USB ports 1 and 2 so provide binding information
for them.
Use usbhs_init_phys() to register the PHY's RESET regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-3430sdp.c | 47
Add platform device for 'nop-usb-xceiv'. This will be used as a
PHY for HS USB Port 2, so provide binding information for it.
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3beagle.c | 44 +++
Use usbhs_init_phys() to register the PHY's VCC and RESET
regulators.
The VCC and RESET will then be managed by the PHY driver.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap4panda.c | 37 +--
1 files changed, 11 insertions(+), 26 deletions(-)
dif
Add platform device and data for 'nop-usb-xceiv'. This will be used
as PHY for HS USB port 1, so provide binding information for it.
Get rid of managing the PHY clock as it will be done by the PHY driver.
For that to work we create a clock alias that links the PHY clock name
to the PHY device name
This helper allows board support code to add the PHY's
VCC and RESET regulators which are GPIO controlled.
It also links the "vcc" and "reset" supplies to the
PHY's device ID that is supplied in the struct usbhs_phy_data
argument.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/usb-host.c
Add clk_rate parameter to platform data. If supplied, the
NOP phy driver will program the clock to that rate during probe.
Also add 2 flags, needs_vcc and needs_reset.
If the flag is set and the regulator couldn't be found
then the driver will bail out with -EPROBE_DEFER.
Signed-off-by: Roger Qua
Hi Tony,
These patches provide the SoC side code required to support
the changes in the OMAP USB Host drivers done in [1], [2] & [3].
Device tree support is added for Beagleboard and Panda.
NOTE: The first patch needs to be shared between the
OMAP tree and Felipe's USB tree.
v2:
- Added helper
Hello,
It took me some time to get back to this topic due to my holidays and other
urgent issues. I hope that this I will be able to participate a bit more
actively.
On 2/14/2013 10:30 PM, Sascha Hauer wrote:
Hi Marek,
On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote:
> Hello
On 09:58-20130315, Jon Hunter wrote:
>
> On 03/15/2013 09:38 AM, Nishanth Menon wrote:
> > On 09:26-20130315, Jon Hunter wrote:
> >>
> >> On 03/15/2013 08:56 AM, Nishanth Menon wrote:
> >>> On 16:44-20130314, Jon Hunter wrote:
> >>>
On 09:56-20130315, Jon Hunter wrote:
[..]
> > But, that said, there is one path I see possible:
> > - keep omap-cpufreq alive (BUT I will add a patch that will not let it init
> > when in DT entries are present)
> > - add DT entries for all relevant OMAPs - in DT mode, we
On 03/15/2013 09:38 AM, Nishanth Menon wrote:
> On 09:26-20130315, Jon Hunter wrote:
>>
>> On 03/15/2013 08:56 AM, Nishanth Menon wrote:
>>> On 16:44-20130314, Jon Hunter wrote:
>>>>
>>>> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
>>>
On 03/15/2013 09:21 AM, Nishanth Menon wrote:
> On 10:48-20130315, Santosh Shilimkar wrote:
>> On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
>>> The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
>>> for doing CPU DVFS using cpu
On 3/15/2013 6:56 PM, Manjunathappa, Prakash wrote:
> Hi Sekhar,
>
> On Thu, Feb 28, 2013 at 16:09:47, Nori, Sekhar wrote:
>> Prakash,
>>
>> On 2/19/2013 2:02 PM, Manjunathappa, Prakash wrote:
>>> DT kernel with latest of denx SPL U-boot boots with garbled UART
>>> logs. This is because in U-boo
On 09:26-20130315, Jon Hunter wrote:
>
> On 03/15/2013 08:56 AM, Nishanth Menon wrote:
> > On 16:44-20130314, Jon Hunter wrote:
> >>
> >> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> >>> Add DT OPP table for OMAP36xx family of devices. This data is
Hi Jon,
On 03/15/2013 02:57 PM, Jon Hunter wrote:
> Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
>
> The DMA, PMU and OMAP3430 SDP board changes have been sent before
> individually but re-sending here as a complete series for v3.10.
>
> This is based upon Benoit's for_3
On 03/15/2013 08:56 AM, Nishanth Menon wrote:
> On 16:44-20130314, Jon Hunter wrote:
>>
>> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
>>> Add DT OPP table for OMAP36xx family of devices. This data is
>>> decoded by OF with of_init_opp_table() helper function. This
>>> overrides the default OMAP
On Thu, Mar 14, 2013 at 11:51 PM, Viresh Kumar wrote:
> On Fri, Mar 15, 2013 at 2:28 AM, Nishanth Menon wrote:
>> We can now use cpufreq-cpu0 driver using DT entries.
>> remove the redundant omap-cpufreq driver from the tree.
>> Remove MAINTAINERS file entry for the same as well.
>>
>> Cc: Kevin
On 10:48-20130315, Santosh Shilimkar wrote:
> On Friday 15 March 2013 02:28 AM, Nishanth Menon wrote:
> > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> > migratin
On 16:49-20130314, Jon Hunter wrote:
>
> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> > OMAP4430 and 4460 have different OPP definitions. So, create an SoC
> > variant dtsi file for 4460 and move the OPP definitions to it.
>
> FYI, I had to create a similar file for PMU [1]. However, I called
Adds basic device-tree support for OMAP3430 SDP board which has 256MB
of RAM, 128MB ONENAND flash, 256MB NAND flash and uses the TWL4030
power management IC.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3430-sdp.dts | 141 +
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC peripheral on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter
Reviewed-by:
The OMAP gpio binding documention [1] states that the #interrupts-cells
property for gpio controllers should be 2. Currently, for OMAP3+ devices
the #interrupt-cells is set to 1. By setting this property to 2, it
allows clients to pass a 2nd parameter indicating the sensitivity (level
or edge) and
The OMAP3 gpio bindings are currently missing the reg and interrupt
properties and so add these properties.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap3.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
i
Add gpios bindings for OMAP2420 and OMAP2430 devices.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420.dtsi | 44 +++
arch/arm/boot/dts/omap2430.dtsi | 55 +++
2 files changed, 99 insertions(+)
diff --git a/arch/arm/boo
Add the device-tree node for GPMC on OMAP2, OMAP4 and OMAP5 devices.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420.dtsi | 11 +++
arch/arm/boot/dts/omap2430.dtsi | 11 +++
arch/arm/boot/dts/omap4.dtsi| 11 +++
arch/arm/boot/dts/omap5.dtsi| 11 ++
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430. The node for OMAP4430 is not included because PMU is not
currently supported on OMAP4430 due to the
If device-tree is present, then do not create the PMU device from within
the OMAP specific PMU code. This is required to allow device-tree to
create the PMU device from the PMU device-tree node.
PMU is not currently supported for OMAP4430 (due to a dependency on
having a cross-trigger interface dr
Various OMAP device-tree updates for PMU, DMA, GPIO, GPMC and boards.
The DMA, PMU and OMAP3430 SDP board changes have been sent before
individually but re-sending here as a complete series for v3.10.
This is based upon Benoit's for_3.10/dts branch [1]. Branch available
here [2].
V2 changes:
- R
On 16:44-20130314, Jon Hunter wrote:
>
> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> > Add DT OPP table for OMAP36xx family of devices. This data is
> > decoded by OF with of_init_opp_table() helper function. This
> > overrides the default OMAP34xx CPU OPP table definition.
>
> Not sure I fol
On 16:42-20130314, Jon Hunter wrote:
>
> On 03/14/2013 03:58 PM, Nishanth Menon wrote:
> > The following series arose from trying to use BeagleBoard-XM (OMAP3 variant)
> > for doing CPU DVFS using cpufreq-cpu0. This series will eventually result in
> > migrating the cpufreq support only through de
The drivers sets up an irq domain and hands out unique virqs to irq
capable gpio lines regardless of which underlying irqs maps to which gpio
line.
Signed-off-by: Andreas Larsson
---
.../devicetree/bindings/gpio/gpio-grgpio.txt |5 +
drivers/gpio/gpio-grgpio.c |
This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP
core library from Aeroflex Gaisler.
Signed-off-by: Andreas Larsson
---
.../devicetree/bindings/gpio/gpio-grgpio.txt | 24 +++
drivers/gpio/Kconfig |9 ++
drivers/gpio/Makefile
There is no general support for 64-bit big endian accesses, so that is
left unsupported.
Signed-off-by: Andreas Larsson
---
drivers/gpio/gpio-generic.c | 56 ---
include/linux/basic_mmio_gpio.h |1 +
2 files changed, 48 insertions(+), 9 deletions(-)
Differences since v4:
- Split out changes to gpio-generic into patch 1
- Make the basic driver without any irq support into patch 2, so that
things can be applied so far if more revisions needs to be done for
the irq support parts.
- Change irq support to use irq domain and put it in patch 3
S
On Friday 15 March 2013 06:11 PM, Benoit Cousson wrote:
+ Jon
Hi Kishon,
On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote:
Hi Benoit,
Here are the dt data patches to get usb device functional in OMAP platforms.
All the patches deal with modifying arch/arm/boot except one which modifies
D
The binding documentation for the OMAP GPIO controller has the
"#interrupt-cells" property listed before "#interrupt-controller"
property but its description after.
This is confusing so we move "#interrupt-cells" after the
"interrupt-controller" property so is followed by its description.
While be
Hi Sekhar,
On Thu, Feb 28, 2013 at 16:09:47, Nori, Sekhar wrote:
> Prakash,
>
> On 2/19/2013 2:02 PM, Manjunathappa, Prakash wrote:
> > DT kernel with latest of denx SPL U-boot boots with garbled UART
> > logs. This is because in U-boot UART2 gets sourced by PLL0_SYSCLK2
> > configured for 150MHz
On Fri, Mar 15, 2013 at 1:56 PM, Benoit Cousson wrote:
> Hi Javier,
>
> On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
>> On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
>> wrote:
>>> The binding documentation for the OMAP GPIO controller has the description
>>> for the "#interr
Le 03/15/13 14:05, David Miller a écrit :
From: Florian Fainelli
Date: Fri, 15 Mar 2013 13:53:10 +0100
Le 03/15/13 13:55, David Miller a écrit :
From: David Miller
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
From: Florian Fainelli
Date: Thu, 14 Mar 2013 19:08:31 +0100
This patch convert
From: Florian Fainelli
Date: Fri, 15 Mar 2013 13:53:10 +0100
> Le 03/15/13 13:55, David Miller a écrit :
>> From: David Miller
>> Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
>>
>>> From: Florian Fainelli
>>> Date: Thu, 14 Mar 2013 19:08:31 +0100
>>>
This patch converts the mv643xx_eth driv
Le 03/15/13 13:55, David Miller a écrit :
From: David Miller
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
From: Florian Fainelli
Date: Thu, 14 Mar 2013 19:08:31 +0100
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a
Hi Javier,
On 03/15/2013 01:18 PM, Javier Martinez Canillas wrote:
> On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
> wrote:
>> The binding documentation for the OMAP GPIO controller has the description
>> for the "#interrupt-cells" property after the "interrupt-controller".
>> This is
From: David Miller
Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT)
> From: Florian Fainelli
> Date: Thu, 14 Mar 2013 19:08:31 +0100
>
>> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
>> instead of rolling its own implementation. As a result, all users of this
>> mv643
Le 03/15/13 13:53, David Miller a écrit :
From: Florian Fainelli
Date: Thu, 14 Mar 2013 19:08:31 +0100
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a result, all users of this
mv643xx_eth driver are converted to regi
From: Florian Fainelli
Date: Thu, 14 Mar 2013 19:08:31 +0100
> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
> instead of rolling its own implementation. As a result, all users of this
> mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
>
+ Jon
Hi Kishon,
On 03/07/2013 02:35 PM, Kishon Vijay Abraham I wrote:
> Hi Benoit,
>
> Here are the dt data patches to get usb device functional in OMAP platforms.
>
> All the patches deal with modifying arch/arm/boot except one which modifies
> Documentation/../usb/omap-usb.txt
>
> Changes f
On Mon, Mar 4, 2013 at 9:56 PM, Javier Martinez Canillas
wrote:
> The binding documentation for the OMAP GPIO controller has the description
> for the "#interrupt-cells" property after the "interrupt-controller".
> This is confusing so is better to move the "interrupt-controller" after
> "#interru
On 14 March 2013 02:10, Doug Anderson wrote:
> Without this change the exynos adc controller needed to have its phy
> enabled in some out-of-driver C code. Add support for specifying the
> phy enable register by listing it in the reg list.
>
> Signed-off-by: Doug Anderson
Worked for me, Its nee
Dear Florian Fainelli,
On Fri, 15 Mar 2013 12:07:12 +0100, Florian Fainelli wrote:
> Thanks to the help of Andrew Lunn, there is at least two known issues
> with this patch version:
>
> - we need to move up the mvmdio line in
> drivers/net/ethernet/marvell/Makefile to make sure that configs ha
On Fri, Mar 8, 2013 at 12:14 AM, Jon Hunter wrote:
>
> On 03/02/2013 02:05 PM, Grant Likely wrote:
>> On Tue, 26 Feb 2013 17:01:22 -0600, Jon Hunter wrote:
>>>
>>> On 02/26/2013 04:44 PM, Stephen Warren wrote:
On 02/26/2013 03:40 PM, Jon Hunter wrote:
> On 02/26/2013 04:01 AM, Javier Mar
Le 03/14/13 19:08, Florian Fainelli a écrit :
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver
Hi Mark,
On 3/7/2013 11:56 AM, Vishwanathrao Badarkhe, Manish wrote:
> Add device tree data for regulator via tps6507x mfd device
> in da850-evm.
> Applies on top of v3.9-rc1 of linus tree.
I would like to take this series via the davinci tree to manage
dependencies with rest of the DT patches.
Hi Kishon,
On 03/13/2013 10:11 AM, kishon wrote:
> Benoit,
>
> Will you be queuing this patch series?
I'm reviewing them right now.
Regards,
Benoit
>
> Thanks
> Kishon
>
> On Thursday 07 March 2013 07:05 PM, Kishon Vijay Abraham I wrote:
>> Hi Benoit,
>>
>> Here are the dt data patches to ge
On 03/14/2013 06:54 PM, Tony Lindgren wrote:
> * Roger Quadros [130314 08:45]:
>>
>> OK. Let me know how the below patch looks. After that, the board code
>> will look like.
>>
>> static struct usbhs_phy_data phy_data[] = {
>> {
>> .reset_gpio = 147,
>> .vcc_gpio = 1
On Fri, Mar 15, 2013 at 11:42:48AM +0800, Shawn Guo wrote:
> On Thu, Mar 14, 2013 at 02:08:32PM +0100, Markus Pargmann wrote:
> > On Wed, Mar 13, 2013 at 10:18:29AM +0800, Shawn Guo wrote:
> > > On Tue, Mar 12, 2013 at 07:02:07PM +, Mark Brown wrote:
> > > > On Sun, Mar 10, 2013 at 07:33:09PM +
1 - 100 of 109 matches
Mail list logo
