On Thu, Nov 19, 2009 at 01:09:23PM +0100, Marek Szyprowski wrote:
> What if a device does not operate properly when clocked from one of the
> available clock sources (lets say machine specific problem)? There must
> be a way of setting which clock(s) should not be considered when calculating
> best
On Thu, Nov 19, 2009 at 9:09 PM, Marek Szyprowski
wrote:
> Hello,
>
> On Thursday, November 19, 2009 12:49 PM Mark Brown wrote:
>
>> On Thu, Nov 19, 2009 at 11:38:41AM +, Russell King - ARM Linux wrote:
>>
>> > I'm not sure what you're commenting on precisely, but the Samsung code as
>> > a wh
On Thu, Nov 19, 2009 at 01:09:23PM +0100, Marek Szyprowski wrote:
> On Thursday, November 19, 2009 12:49 PM Mark Brown wrote:
> > My suggestion was to push this logic down into the clock API so the
> > serial driver just requests a rate and then clock API picks the best
> > option from the mux. A
Hello,
On Thursday, November 19, 2009 12:49 PM Mark Brown wrote:
> On Thu, Nov 19, 2009 at 11:38:41AM +, Russell King - ARM Linux wrote:
>
> > I'm not sure what you're commenting on precisely, but the Samsung code as
> > a whole doesn't use the clk API very well, and I suspect that is starti
On Thu, Nov 19, 2009 at 8:48 PM, Mark Brown
wrote:
> On Thu, Nov 19, 2009 at 11:38:41AM +, Russell King - ARM Linux wrote:
>
>> I'm not sure what you're commenting on precisely, but the Samsung code as
>> a whole doesn't use the clk API very well, and I suspect that is starting
>> to cause peo
On Thu, Nov 19, 2009 at 11:48:33AM +, Mark Brown wrote:
> On Thu, Nov 19, 2009 at 11:38:41AM +, Russell King - ARM Linux wrote:
>
> > I'm not sure what you're commenting on precisely, but the Samsung code as
> > a whole doesn't use the clk API very well, and I suspect that is starting
> >
On Thu, Nov 19, 2009 at 11:38:41AM +, Russell King - ARM Linux wrote:
> I'm not sure what you're commenting on precisely, but the Samsung code as
> a whole doesn't use the clk API very well, and I suspect that is starting
> to cause people to have to pass clock names around.
That's what I'd t
On Thu, Nov 19, 2009 at 11:08:27AM +, Mark Brown wrote:
> On Thu, Nov 19, 2009 at 08:05:29PM +0900, jassi brar wrote:
> > On Thu, Nov 19, 2009 at 7:33 PM, Mark Brown
>
> > > This is going to set off warnings from a clock API point of view -
> > > passing clock names around in platform data is
On Thu, Nov 19, 2009 at 08:26:34PM +0900, jassi brar wrote:
> The case here is that UART controller can source from various platform clocks
> to generate the UART clocks. The drivers/serial/samsung.c chooses a source
> clock that can result in closest match to the requested rate.
> How could we do
On Thu, Nov 19, 2009 at 8:08 PM, Mark Brown
wrote:
> On Thu, Nov 19, 2009 at 08:05:29PM +0900, jassi brar wrote:
>> On Thu, Nov 19, 2009 at 7:33 PM, Mark Brown
>
>> > This is going to set off warnings from a clock API point of view -
>> > passing clock names around in platform data is usually a si
On Thu, Nov 19, 2009 at 08:05:29PM +0900, jassi brar wrote:
> On Thu, Nov 19, 2009 at 7:33 PM, Mark Brown
> > This is going to set off warnings from a clock API point of view -
> > passing clock names around in platform data is usually a sign that
> > something is very wrong. Keeping the mapping
On Thu, Nov 19, 2009 at 7:33 PM, Mark Brown
wrote:
> On Thu, Nov 19, 2009 at 11:44:14AM +0900, jassi brar wrote:
>
>> Let each platform code(SoC specific) define names of all possible
>> source clocks and let the board init code pass on the potential source
>> clocks by some bit-mask(or some other
On Thu, Nov 19, 2009 at 11:44:14AM +0900, jassi brar wrote:
> Let each platform code(SoC specific) define names of all possible
> source clocks and let the board init code pass on the potential source
> clocks by some bit-mask(or some other mechanism) while setting the
> platform data.
This is go
On Thu, Nov 19, 2009 at 7:13 AM, Ben Dooks wrote:
> On Wed, Nov 18, 2009 at 11:14:52PM +0900, jassi brar wrote:
>> On Wed, Nov 18, 2009 at 10:33 PM, Marek Szyprowski
>> wrote:
>> > From: Kyungmin Park
>> >
>> > Samsung S5PC110 SoCs have UART that differs a bit from the one known
>> > from the pr
On Wed, Nov 18, 2009 at 11:14:52PM +0900, jassi brar wrote:
> On Wed, Nov 18, 2009 at 10:33 PM, Marek Szyprowski
> wrote:
> > From: Kyungmin Park
> >
> > Samsung S5PC110 SoCs have UART that differs a bit from the one known
> > from the previous Samsung SoCs. This patch adds support for this new
>
On Wed, Nov 18, 2009 at 10:33 PM, Marek Szyprowski
wrote:
> From: Kyungmin Park
>
> Samsung S5PC110 SoCs have UART that differs a bit from the one known
> from the previous Samsung SoCs. This patch adds support for this new
> driver.
>
> Signed-off-by: Kyungmin Park
> Signed-off-by: Marek Szypro
From: Kyungmin Park
Samsung S5PC110 SoCs have UART that differs a bit from the one known
from the previous Samsung SoCs. This patch adds support for this new
driver.
Signed-off-by: Kyungmin Park
Signed-off-by: Marek Szyprowski
---
arch/arm/plat-s3c/include/plat/regs-serial.h | 31 ++
17 matches
Mail list logo
