On 12/03/2015 03:51 PM, Vignesh R wrote:
>
>
> On 12/01/2015 10:09 PM, Tony Lindgren wrote:
>> * Vignesh R [151130 20:46]:
>>> On 12/01/2015 04:04 AM, Tony Lindgren wrote:
...
>>
>> OK. They are both on L3 main so that won't cause any issues for separate
>> interconnect driver instances.
Commit 1f71e8c96fc654724723ce987e0a8b2aeb81746d ("drivers: net: cpsw: Add
support for fixed-link PHY") used a 'goto no_phy_slave' to skip over the
processing of the mutually-exclusive "phy_id" property. Unfortunately that
also skipped the "phy-mode" property processing, leaving slave_data->phy_if
w
On Wed, Dec 09, 2015 at 01:10:18PM +0200, Peter Ujfalusi wrote:
> Hi Arnd, Vinod,
>
> As Arnd suggested, the two patch from the following series:
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122201.html
>
> plus Acked-by from Arnd is available for pull if you prefer that way.
Sor
On Wed, Dec 09, 2015 at 12:12:27PM -0800, Tony Lindgren wrote:
> * Peter Ujfalusi [151209 00:19]:
> > Hi,
> >
> > Based on the discussion regarding to (convert am33xx to use the new eDMA
> > bindings):
> > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
> >
> > This two pa
On 09.12.2015 22:12, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
>
* Tero Kristo [151208 23:50]:
> On 12/08/2015 10:11 PM, Tony Lindgren wrote:
> >* Tero Kristo [151208 11:25]:
> >>On 12/08/2015 06:57 PM, Tony Lindgren wrote:
> >>>
> >>>Anybody from the clock department care to ack this one?
> >>
> >>Sorry been rather busy lately...
> >>
> >>>I'd like to
> >>>ge
* Felipe Balbi [151208 10:05]:
>
> Hi,
>
> Grygorii Strashko writes:
> > ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> > But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> > Timekeeping core misbehaves. For example, execution of command
> > "sleep
On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
...
> @@ -55,16 +54,16 @@ static int moxart_gpio_probe(struct platform_device *pdev)
> return ret;
> }
>
> - bgc->gc.label = "moxart-gpio";
> - bgc->gc.request = gpiochip_generic_request;
> - bgc->gc.fr
Hi,
(please avoid top-posting)
Ryan writes:
> Hi Tony,
>
> Thanks for your response. I dont see any prints. I suspect that it
> might be hanging before the serial port is initialized
>
> All i see is after arch_reset is called. I can see that is mmc clk and
> data signals toggling. This makes m
Hi Tony,
Thanks for your response. I dont see any prints. I suspect that it
might be hanging before the serial port is initialized
All i see is after arch_reset is called. I can see that is mmc clk and
data signals toggling. This makes me think that
boot rom has loaded the xloader into sram.
Tha
* Ryan [151209 09:03]:
> Hello,
>
> On a custom 4460 board. The x-loader hangs at some place when we
> reboot. This happens occasionally on an android port by linaro.
>
> I just want to find out how to debug in this case. How can i get to
> know where the hang takes place. After boot rom, i can
* Peter Ujfalusi [151209 00:19]:
> Hi,
>
> Based on the discussion regarding to (convert am33xx to use the new eDMA
> bindings):
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
>
> This two patch will convert the new eDMA binding to not use 16bit arrays for
> memcpy chan
On Wed, Dec 09, 2015 at 10:18:11AM +0200, Peter Ujfalusi wrote:
> This change makes the DT file to be easier to read since the reserved slots
> array does not need the '/bits/ 16' to be specified, which might confuse
> some people.
>
> Signed-off-by: Peter Ujfalusi
This too should have info on w
On Wed, Dec 09, 2015 at 10:18:10AM +0200, Peter Ujfalusi wrote:
> This change makes the DT file to be easier to read since the memcpy
> channels array does not need the '/bits/ 16' to be specified, which might
> confuse some people.
Why? I don't see the point of this change and plus you are breaki
On Wed, Dec 09, 2015 at 02:02:00PM -0600, Rob Herring wrote:
> On Wed, Dec 09, 2015 at 10:18:10AM +0200, Peter Ujfalusi wrote:
> > This change makes the DT file to be easier to read since the memcpy
> > channels array does not need the '/bits/ 16' to be specified, which might
> > confuse some peopl
* Linus Walleij [151209 05:14]:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a struct, making several
> steps of
On 12/09/2015 05:24 PM, Bjorn Helgaas wrote:
On Tue, Dec 08, 2015 at 10:05:56AM +0100, Sebastian Andrzej Siewior wrote:
* Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:
The backtrace might be OK (maybe slightly overkill), but all the
stack addresses are certainly irrelevant and distracting. We
On Wednesday, December 09, 2015 6:13 AM, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a stru
Hello,
On a custom 4460 board. The x-loader hangs at some place when we
reboot. This happens occasionally on an android port by linaro.
I just want to find out how to debug in this case. How can i get to
know where the hang takes place. After boot rom, i can see the mmc clk
toggling
indicating th
On Wed, Dec 09, 2015 at 02:12:40PM +0100, Linus Walleij wrote:
> The separate struct bgpio_chip has been a pain to handle, both
> by being confusingly similar in name to struct gpio_chip and
> for being contained inside a struct so that struct gpio_chip
> is contained in a struct contained in a str
On Tue, Dec 08, 2015 at 10:05:56AM +0100, Sebastian Andrzej Siewior wrote:
> * Bjorn Helgaas | 2015-12-04 12:46:19 [-0600]:
>
> >The backtrace might be OK (maybe slightly overkill), but all the
> >stack addresses are certainly irrelevant and distracting. We only
> >need enough to recognize the pr
> I guess will be interesting cc'ing the ISEE people. Added Agusti and Pau.
>
> Thanks,
> Enric
Thank you.
Ack.
We will try with new versions (wilink8)
Agusti
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More m
The separate struct bgpio_chip has been a pain to handle, both
by being confusingly similar in name to struct gpio_chip and
for being contained inside a struct so that struct gpio_chip
is contained in a struct contained in a struct, making several
steps of dereferencing necessary.
Make things simp
Hi Arnd, Vinod,
As Arnd suggested, the two patch from the following series:
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122201.html
plus Acked-by from Arnd is available for pull if you prefer that way.
Regards,
Péter
===
On Wednesday 09 December 2015 10:18:09 Peter Ujfalusi wrote:
> Hi,
>
> Based on the discussion regarding to (convert am33xx to use the new eDMA
> bindings):
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
>
> This two patch will convert the new eDMA binding to not use 16b
Hi Brian,
On Tue, 8 Dec 2015 16:17:41 -0800
Brian Norris wrote:
>
> > diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
> > index 43bded6..84d027e 100644
> > --- a/drivers/mtd/nand/cmx270_nand.c
> > +++ b/drivers/mtd/nand/cmx270_nand.c
> > @@ -160,10 +160,8 @@ static
This change makes the DT file to be easier to read since the reserved slots
array does not need the '/bits/ 16' to be specified, which might confuse
some people.
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 ++--
drivers/dma/edma.c
On 13/11/15 12:29, H. Nikolaus Schaller wrote:
> Otherwise check_timings fails and we get a "has no modes" message
> from xrandr.
>
> This fix makes the venc assume PAL and NTSC timings that match the
> timings synthetized by copy_timings_drm_to_omap() from omapdrm
> mode settings so that check_t
This change makes the DT file to be easier to read since the memcpy
channels array does not need the '/bits/ 16' to be specified, which might
confuse some people.
Signed-off-by: Peter Ujfalusi
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 5 ++---
drivers/dma/edma.c
Hi,
Based on the discussion regarding to (convert am33xx to use the new eDMA
bindings):
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html
This two patch will convert the new eDMA binding to not use 16bit arrays for
memcpy channel selection and for marking slots reserved.
The
Hi Brian,
On Tue, 8 Dec 2015 16:36:24 -0800
Brian Norris wrote:
> Hi,
>
> On Tue, Dec 01, 2015 at 12:02:57PM +0100, Boris Brezillon wrote:
> > Hello,
> >
> > This huge series aims at clarifying the relationship between the mtd and
> > nand_chip structures and hiding NAND framework internals to
31 matches
Mail list logo