loopback works then please let me know.
Thanks for the fix,
Sean
On Mon, 12 Feb 2001 22:28:28 + (GMT), Alan Cox said:
> > > That was Im afraid pure luck. Jens is currently sorting out the
> > > loop problems and has test patches
> >
> > By any chance, ar
e reverse
engineering. Instead he chose to insult and question the motives of
everyone that wanted open-source access to the Linux history data. The
blame for the current situation falls firmly on the choice to use a
closed-source SCM for Linux and the actions of the company that owned it.
Sean
kernel code in
> kernel modules will, eventually, fail completely unless we
> only get binaries with no source-code. Even in that case,
> many symbols within /proc/kallsyms are useful.
>
Yeah yeah.. yet another brilliant idea from the peanut gallery. GPL_
symbols aren't mean
l these arguments that we can't support an advanced future
design unless the new design also supports $10 third world video cards too
is a complete red herring.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL P
he comment from
Dave as something like "Nobody who matters, with regard to kernel
development, cares about NDISwrapper". If _you_ care, fork your own tree
and maintain the patch as necessary.
Regards,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
sue, it's what Linux _is_: an open source
operating system! That's what the developers are working on; not your
half-baked vision. If you want to create some bastardized version and are
willing to commit dollars and effort to maintaining the code needed to do
so, feel free.
Regards,
Sean
e minded people to provide crap kernels and shitty binary
drivers to people who don't know better. So don't worry, your well
intentioned vision of the future will survive the removal of 8K stacks
from the kernel.
Regards,
Sean
-
To unsubscribe from this list: send the line "u
d a copy of
Windows!!!" Do you think they should stop charging for Windows to help
you out?? Get real.
Please just do whatever you want and stop hoping that open source
developers will ever care about your choice to embrace binary-only
drivers.
Cheers,
Sean
-
To unsubscribe from this list: se
evelopers should spend any time worrying about it or not.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
d at all, even for NDISwrapper.
4K stacks were NOT invented to hassle binary-only driver owners, they were
created to solve problems associated with 8K stacks.. Leaving the 8K
stack option in the kernel signals that it is a _good_ option. That just
isn't true, so the option should be remov
own mailing list etc..
> Keeping it marked as BROKEN is fine. It may even taint the kernel, that's
> not a problem. Removing it is wrong.
I agree with you that it should taint at a minimum. But should something
that taints the kernel even be part of the mainline source?
Cheers,
Se
ce did. For
example, the above procedure in raw git, is:
git clone
rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6
cd linux-2.6
make menuconfig
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
ware options on a lappie, you take what you get, you get what you
> can afford, and often that means running on what someone else chooses.
So?
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majord
I used to find the main line bk snapshots in:
pub/mirrors/linux/kernel/linux/kernel/v2.6/snapshots
Now there just the 2.6.11.x snapshots.
For instance where is bk10?
sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
could handle returning temperatures without
the caller knowing from where the value was obtained. Isn't this the
exact type of thing that just bloats a kernel needlessly?
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
boards have them now (all but 1 I think).
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
l Xeon box too, with 4 GB of RAM and 2GB of
swap (no NFS) using stock RHEL 4 kernel. The only thing that seems to
keep it from happening is setting /proc/sys/vm/vfs_cache_pressure to
1.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
freedom
to use collected metadata. Since svn or arch could fill the role quite
nicely without these problems, it makes you wonder if the price of BK is
too high for whatever advantage it provides over these other choices.
Unfortunately the decision has already been made, so this is all academic.
too high. It's disappointing to see so many top
developers not give a damn about its costs and ignore the difficulties it
creates for many.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More m
s are cut off. It's a rather large
"hidden" cost of BK adoption as the primary tool at the top.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ke
se unfortunately isn't true; not because of technical
reasons, but because of license restrictions.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majord
; any closer to having said SCM.
Lee,
Your cookie cutter response, proves you didn't really absorb the content
of my message. Please reread; there was no "bitching" at all.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
e not seen anyone else make that
argument here on the list and it is something that Linus may not have
given full consideration to. At least the comment that you quote gives
no consideration to it at all.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, February 17, 2005 3:52 pm, Horst von Brand said:
> "Best tool for the job" certainly includes minutiae like "benefits" and
> "price".
Thank you, that's my point. It's not just about the geeky microscopic
technical details.
Sean
you're
attributing to BK would have been realized with any other SCM system too.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
functionality to a free SCM.
No need to respond.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
, although it's less mature
than the options you cite.
> The important thing for the health of the SCM ecosystem is that there be
> ways to losslessly convert and interoperate between them as well as
> between legacy/centralized systems such as CVS and SVN as well as with
> BK.
Amen.
has pretty much shown
BK is not required, he's still using patches.
Cheers,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Just now there are starting to be halfways useful SCM systems (almost
> all based on the "one central repository" idea, which doesn't cut it
> for Linux), but they aren't proven enough.
Yeah, there are some glimmers of hope for sure, but you're right they're
gt; what's so painful of getting the finely grained changeset through
> bkbits.net? Not very. So at the end of the day, it finally boils
> down to being all about ideology, doesn't it?
No. It's just that the cost isn't being paid by you, so you don't care.
Cheers,
ut we
> alerady have what you have just described.
>
Bitkeeper isn't motivated to raise the bar in terms of implementation, nor
is cvs the best choice in terms of which free tool to use. Once a free
SCM is actually used at the head, there are opportunities to implement
updating too, no
the public :o)
Just that the flow of information wouldn't all have to originate in bk to
make it into head (ie. bk could pull changes from head too).
Cheers,
Sean.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
> that
> no one has heard of that versioning system.
>
> No matter what choice Linus would have made, he would have had some part
> of
> the community pissed at him, so it is ultimately his choice on what to use
> because hes the only one going to be happy with it.
>
> [
ble.
>
Wait a second though, this tree will be branched from the development
mainline. So it will contain many patches that entered with less
testing. What will be the policy for dealing with regressions relative
to the previous $sucker release caused by huge patches that entered via
the
oft. In essense, all they said was they were
willing to share their code with people who were also willing to share.
You're probably better off writing your proprietary driver on a
proprietary operating system.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-
a free ride and don't care about returning
anything to the community that created Linux have many other forums in
which to vent.
Regards,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Randy.Dunlap wrote:
Did you look in
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/old/ ?
Yes I did.
Latest is 2.6.12-rc1-bk2, March 26.
None since then?
sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
period. Adding _GPL to the symbol does not
place any additional restriction on the people who are already bound by
the GPL. You were much easier to endure when you were just pretending to
have invented RLE.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
hat is in full
compliance with the spirit and intent of the GPL. Full Stop.
Runtime restrictions do not fall under the GPL anyway, otherwise it would
be illegal to impose _any_ security restrictions on a GPL system.
You are just DeadWrong(Tm) on this issue.
Sean
-
To unsubscribe from this list
o
net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0): multiple definition of
`ip_nat_tftp_hook'
net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0): first defined here
make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
sean
-
To unsubscribe from this list: send th
This patch worked. Or at least it built.
Thanks for the quick response.
sean
Martin Josefsson wrote:
Try this patch:
diff -X dontdiff.ny -urNp linux-2.6.11-rc2.orig/include/linux/netfilter_ipv4/ip_conntrack_tftp.h linux-2.6.11-rc2/include/linux/netfilter_ipv4/ip_conntrack_tftp.h
--- linux-2.6.11
asked for testers.
Git needs a spec file maintainer so that issues like this can be caught
before release. Without a maintainer, it should probably be demoted
to contrib itself.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
e?
Given the comment from David, I suspect your patch is all
that's needed; hopefully Peter can give it a quick test.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>
> If it were knowingly less difficult to actually get your drivers
> included, that would be an incentive and then you original point would
> hold as an additional incentive.
Out of curiosity what specific technical issues in your driver code make
you think that it would b
On Sun, 7 Jan 2007 15:05:53 -0500
Dave Jones <[EMAIL PROTECTED]> wrote:
Including the Git list...
> On Sun, Jan 07, 2007 at 07:17:30PM +, Russell King wrote:
>
> > commit 24ebead82bbf9785909d4cf205e2df5e9ff7da32
> > tree 921f686860e918a01c3d3fb6cd106ba82bf4ace6
> > parent 264166e604a7e14c
-f mm/page_alloc.c) ...
Please forgive my git fanboyism, but assuming you have no
uncommitted changes in your working tree, you could also:
$ git revert -n d09c6b809432
... build and test ...
$ git reset --hard
... back to original ...
cheers,
Sean
-
To unsubscribe from this list: send the
e ISO C.
There's no rule that says /bin/sh is always /bin/bash. What Novell
distributions do does not translate to all of "Linux". If you are writing
scripts that rely on bash then "#!/bin/bash" is the appropriate way to
document that and give it the best chance of worki
the problems of bouncing
> back out to userspace for file creation and renames it looks like a regex
> in the kernel is a lot safer and more reliable.
There hasn't yet been shown a requirement for a userspace daemon to implement
AA over SeLinux.
Sean
-
To unsubscribe from this list: se
in general to others. But
from what i can tell, it's the only significant difference between
SELinux and AA.
Depending on the way it was implemented, its conceivable that users could
mix and match native SELinux policy with custom AA policies as they
saw fit.
Sean
-
To unsubscribe from this
you get code back, the FSF think its fair that people can hack
and run the code anywhere its used.. It all comes down to the
author of the code getting to attach whatever restrictions they
choose.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
king about _degree_ of
restriction.
There's no problem with people voicing honest disagreement with the v3,
but please lighten up a bit on FSF bashing and the Greek tragedy talk.
Sean.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
ose the problem further.
Thanks,
Sean
[1] http://www.ussg.iu.edu/hypermail/linux/kernel/0703.3/0349.html
dmesg (ata1.00: limited to UDMA/33 due to 40-wire cable):
Linux version 2.6.22-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2))
#6 SMP PREEMPT Sun Jun 3 14:45:47 EDT 2007
BIOS-provid
oblem.
As an aside, booting the patch-reverted rc4 does not resolve the other
issue I just reported to the list[1] (sorry for not cc'ing you).
Cheers.
Sean
[1] http://marc.info/?l=linux-kernel&m=118109439301092&w=2
-
To unsubscribe from this list: send the line "unsubscribe li
use TF interface for polling NODATA commands".
Thanks,
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ove (bind-mounts,hard links etc).
So why can't those decisions be turned into labels that are fed into SELinux
enforcement code?
Sean.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> no need or push to try and secure everything all at once, and no need to
> re-label files (and change any policies that used the old labels) when
> you discover a new interaction.
And so it could remain; this is about implementation, not model.
Sean
-
To unsubscribe from this list: sen
at decides the proper policy for each path. Why
not use it to feed labels into SELinux.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Plea
infrastructure.
Let's assume that everyone agrees that AA is a good idea. Which parts of it
absolutely can't be implemented in terms of SELinux? SELinux isn't fixed in
stone, it can be altered if necessary to accommodate AA (as in the example
above of becoming default-deny).
Sean
m and so the policy that's needed is different.
You seem to be quibbling over small little unimportant details and refusing
to part with your current implementation. It would seem the easiest way to
get the functionality you want into the kernel is to be a bit more flexible
on implementation.
Sean
-
unch of
new stuff into the kernel that could instead be added as a small
extension to what already exists.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
;
Calling LSM "core" and pretending that SELinux can't do 90% of what you
want doesn't change the facts on the ground. Clinging to the current AA
implementation instead of honestly considering reasonable alternatives
does not inspire confidence or teamwork.
Sean.
-
To unsubscri
t; if the SELinux people had responded to the announcement of AA with "that's
> a nice idea, if we add these snippits from your code to SELinux then we
> can do the same thing" it would be a very different story.
To be fair, that's not their job.
> but as always patch
On Sat, 9 Jun 2007 20:26:57 +0900
Tetsuo Handa <[EMAIL PROTECTED]> wrote:
> Sean wrote:
> > All of a sudden you've implemented the main features of AA with very
> > few changes to the kernel. It should be more maintainable, and much
> > easier to get accepted into
On Sat, 9 Jun 2007 17:17:57 +0200
Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Saturday 09 June 2007 10:10, Sean wrote:
> > Clinging to the current AA implementation instead of honestly considering
> > reasonable alternatives does not inspire confidence or teamwork.
&
concerned, AppArmor _is_ meant to replace
SELinux. Not that there is really anything wrong with that, but it's
a little disingenuous to then argue that they're meant to coexist.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
This patch fix a minor checkpath warming:
"WARNING: line over 80 characters"
Signed-off-by: Sean
---
drivers/staging/dgnc/dgnc_neo.c | 116
1 file changed, 82 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drive
This patch fix a minor checkpath warming:
"WARNING: line over 80 characters"
Signed-off-by: Sean Wei
---
drivers/staging/dgnc/dgnc_neo.c | 116
1 file changed, 82 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c
I'm pretty sure the Git guys would agree to
distribute checkpatch.pl along with the existing pre-commit hook. So
at least enabling checkpatch would be trivial for those convinced to
use it.
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, 17 Sep 2007 09:15:31 -0400
Jason Dixon <[EMAIL PROTECTED]> wrote:
> Sure it does. My code under BSD license continues to remain free,
> regardless of what Company X(1) does with their *copy* of my code.
> The only restrictions on my code is that copyright and attribution
> must r
This patch fix a minor checkpath warming:
"WARNING: line over 80 characters"
Signed-off-by: Sean
---
drivers/staging/dgnc/dgnc_neo.c | 116
1 file changed, 82 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drive
On Sun, Feb 03, 2013 at 03:47:45PM +0100, Ben Hutchings wrote:
> 3.2-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Sean Young
>
> commit 65ecc9c02dbad033a73a32916d17c107c5b25031 upstream.
>
> The legacy se
Reviewed-by: Sean Hefty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
the arch-
specific bits for exynos5.
Changes in v3:
- Use compatible field in device tree instead of hdmi-version field
- Change hdmi driver's naming to use IP version instead of hdmi version
Sean Paul (2):
drm/exynos: Get HDMI version from device tree
ARM: Change exynos5-hdmi referenc
With the change "drm/exynos: Get HDMI version from device tree",
exynos5-hdmi is no longer relevant. Update references to exynos4-hdmi
and update the hdmi compatibility string to accurately reflect the hdmi
driver.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250.dtsi
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
> n 02/05/2013 04:42 PM, Sean Paul wrote:
>> Use the compatible string in the device tree to determine which
>> registers/functions to use in the HDMI driver. Also changes the
>> references from v13 to 4210 and v14 to 4
On Tue, Feb 5, 2013 at 4:42 PM, Stephen Warren wrote:
> On 02/05/2013 05:37 PM, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
>>>> Use the compatible string in the device tree to determine whi
> * drivers/infiniband/core/cm.c:cm_alloc_id()
> drivers/infiniband/hw/mlx4/cm.c:id_map_alloc()
>
> Used to wrap cyclic @start. Can be replaced with max(next, 0).
> Note that this type of cyclic allocation using idr is buggy. These
> are prone to spurious -ENOSPC failure after the first
> So, if you want a cyclic allocation, the allocation should be tried in
> [start, END) and then [0, start); otherwise, after the allocation
> wraps for the first time, as the closer the starting point gets to
> END, the chance of not finding a vacant slot in [start, END) goes
> higher. When @star
e for the port on 3.8.3.
> >
> > The offending commit mentions this is a BIOS bug from InsydeH2O and that
> > the port is bogus in that case, but we have something similar here with
> > an AMI UEFI implementation (Version: 0406 Release Date: 06/06/2012)
> > where t
On Tue, Apr 02, 2013 at 05:34:35PM +0100, Sean Young wrote:
> On Tue, Apr 02, 2013 at 09:23:36AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Apr 02, 2013 at 11:53:44AM -0400, Josh Boyer wrote:
> > > Hi All,
> > >
> > > We've had a report [1] that t
(8250_pnp: do pnp probe
before legacy probe) we get a bogus ttyS0, which prevents the legacy
probe from detecting it.
Reported-by: Vincent Deffontaines
Tested-by: Vincent Deffontaines
Signed-off-by: Sean Young
Cc: sta...@vger.kernel.org
---
drivers/tty/serial/8250/8250_pnp.c | 12
On Sat, Sep 01, 2012 at 09:57:09AM +0800, Du, Changbin wrote:
> From: "Du, Changbin"
>
> Each rc-raw device has a property "allowed_protos" stored in structure
> ir_raw_event_ctrl. But it didn't work because all decoders would be
> called when decoding. This path makes only allowed protocol decod
t to be able to multiple remotes on the IR device (which
you can do as long as the scancodes don't overlap, I think), and the
lirc device is implemented as a decoder, so you might want to see the
raw IR as well as have it decoded.
> And if that will lead to a issue that each decode
Acked-by: Sean MacLennan
Worked for me ;)
Cheers,
Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul
---
drivers/gpu
This patch adds a node for the ptn3460 DP-LVDS chip in the
exynos5250-snow board dts file.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts
This set adds some missing devicetree nodes to the exynos5250-snow file as well
as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in
the exynos5250-snow board.
Sean
Sean Paul (5):
ARM: dts: Add fimd display-timings for exynos5250-snow
ARM: dts: Add dp-controller node
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index
This patch adds the internal panel timings to the exynos5250-snow board
dts file.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250-snow.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250
On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
> Hi, thank you for your contribution and the below is my short comments,
>
> 2013/10/2 Sean Paul :
>> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
>> bridge chip.
>>
>> Signed-off-by: Sea
On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
> 2013/10/2 Sean Paul :
>> This patch adds code to look for the ptn3460 in the device tree file on
>> exynos initialization. If ptn node is found, the driver will initialize
>> the ptn3460 driver and skip creating a DP connec
On Wed, Oct 2, 2013 at 5:10 PM, Olof Johansson wrote:
> On Tue, Oct 1, 2013 at 4:40 PM, Sean Paul wrote:
>> This patch adds the dp-controller node to the exynos5250-snow board dts
>> file.
>>
>> Signed-off-by: Sean Paul
>> ---
>> arch/arm/boot/dts/exyn
On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae wrote:
> 2013/10/4 Sean Paul :
>> On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
>>> 2013/10/2 Sean Paul :
>>>> This patch adds code to look for the ptn3460 in the device tree file on
>>>> exynos initializat
On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae wrote:
> 2013/10/3 Sean Paul :
>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>>> Hi, thank you for your contribution and the below is my short comments,
>>>
>>> 2013/10/2 Sean Paul :
>>>> Thi
On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae wrote:
> 2013/10/4 Sean Paul :
>> On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae wrote:
>>> 2013/10/3 Sean Paul :
>>>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>>>>> Hi, thank you for your co
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul
---
v2
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
v2:
- Changed header definition to static inline
- Changed dt node name to lvds-bridge
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm
This set adds some missing devicetree nodes to the exynos5250-snow file as well
as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in
the exynos5250-snow board.
Sean
Sean Paul (5):
ARM: dts: Add fimd display-timings for exynos5250-snow
ARM: dts: Add dp-controller node
1 - 100 of 4464 matches
Mail list logo
